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INTRODUCTION 


PURPOSE. 


The  purpose  of  this  effort  was  to  conduct  satellite  system  configuration/ 
channel  access  cov.trol  (SSC/CAC)  simulation  tests  with  air  traffic  control 
(ATC)  test  subjects  to  determine  controller  reactions  to  the  satellite  modes 
of  communication  and  their  Interaction  with  associated  Input/output  Inter- 
faces. This  effort  was  In  support  of  the  Federal  Aviation  Administration  (FAA) 
Aeronautical  Satellite  (AEROSAT)  program. 

BACKGROUND. 

The  AEROSAT  program  Is  designed  to  develop  the  operational  and  technical 
concepts  of  oceanic  ATC  systems  utilizing  satellite  communications  and  surveil- 
lance capability.  Since  the  cost  of  the  satellite  Is  proportional  to  Its  trans- 
mitter power,  the  AEROSAT  satellites  will  be  limited  In  the  number  of  commu- 
nications channels  available.  The  need  to  maintain  a minimum  signal  level  on 
each  channel  favors  the  use  of  satellite  antenna  spot  beams  rather  than  earth- 
coverage  antenna  patterns.  Because  of  this  design  and  proposed  operation  of 
the  system,  channel  management  and  access  control  will  have  a vital  role  In 
AEROSAT. 

The  satellite  configurations  and  access  techniques  to  provide  services  to  the 
airborne  and  ground  users  have  been  studied  under  FAA  and  Department  of  Trans- 
portation (DOT)  contracts  by  Bell  Aerospace  Company  and  Computer  Sciences 
Corporation.  These  studies  outlined  several  configurations  using  frequency 
division  multiplexing  that  are  technically  feasible  and  show  good  promise 
toward  operational  suitability.  However,  operational  suitability  and  con- 
troller/computer Interfaces  were  not  addressed  In  the  studies. 

In  the  present-day  ATC  domestic  environment,  all  communication  Is  by  voice, 
with  no  data  communication  capability.  The  controller  manages  the  voice  commu- 
nication channels,  and  Initiates  all  pilot  responses.  By  monitoring  the  voice 
channels,  pilots  determine  an  opportune  time  to  call  the  controller,  who  may 
create  queues  by  using  phrases  like  "standby." 

In  the  satellite  environment,  there  will  be  a limited  number  of  available 
voice  channels.  This  will  result  In  controllers  sharing  voice  channels. 
Therefore,  the  controller-managed  system  will  be  difficult  to  Implement.  In 
addition,  aircraft  will  not  be  able  to  monitor  other  alrcraf t-to-ground  commu- 
nications to  determine  an  opportune  time  to  call  the  controller.  As  an  alternate 
communications  management  system,  a computer-controlled  access  to  voice  channels 
will  be  Implemented.  Both  controllers  and  pilots  will  request  use  of  the 
channels.  The  computer  will  grant  the  request  when  the  channel  Is  free. 

Additionally,  data  communication  will  be  available  In  the  satellite  environ- 
ment. Although  limited  experimentation  has  been  done  with  the  controller/ 
computer  Interface  In  domestic  alr/ground  data  communication,  Important 


1 


differences  occur  In  satellite  data  communication.  For  example,  the  delays 
are  greater  due  to  the  lower  bit  rate,  longer  communication  path,  a more 
lengthy  synchronization  prekey,  and  increased  number  of  aircraft  accommodated 
on  a single  polling  channel.  In  the  satellite  environment,  data  communication 
will  probably  be  used  for  less  rigidly  constructed  message  types  than  those 
expected  to  be  employed  in  the  domestic  system  when  it  is  Implemented. 


DISCUSSION 


METHOD  OF  APPROACH. 


It  was  not  expected  nor  an  objective  of  this  effort  that  numerical,  quantita- 
tive data  be  derived  from  the  SSC/CAC  simulation  tests.  For  example,  quantities 
such  as  numbers  of  aircraft  to  be  served  and  average  queuing  times  for  communi- 
cations channel  access  are  best  derived  from  fast-time  computer  models  which 
can  simulate  several  hundred  airborne  and  ground  users.  However,  the  simula- 
tion tests  were  designed  to  provide  preliminary  data  on  air  traffic  controller 
reactions  to  conducting  ground-air-ground  communications  via  data  link  and 
voice  channels  in  an  oceanic  control  environment  supported  by  satellite 
communications  and  surveillance.  Communications  delays  were  Introduced  into 
the  tests  to  approximate  those  delays  that  may  be  encountered  during  actual 
satellite-supported  ATC  operations.  The  tests  were  designed  to  expose  each 
controller  test  subject  to  various  delay  times  and  message  length  and  format 
restrictions.  Data  were  acquired  which  indicated  test  subject  preferences 
and  reactions  to  different  simulation  test  configurations.  Additionally,  data 
were  obtained  for  (1)  controller  reactions  to  data  communication  message  delay 
and  voice  channel  queuing,  and  acceptance  of  satellite  communications  operating 
disciplines,  (2)  an  estimate  of  the  mix  of  voice  and  data  messages  in  controlling 
oceanic  traffic  via  satellite-supported  communications  and  surveillance,  and 
(3)  a determination  of  whether  any  unique  operating  procedures  will  be  needed 
in  any  of  the  proposed  AEROSAT  system  satellite  configurations/channel  access 
control  techniques. 

DESCRIPTION  OF  THE  SIMULATION  TESTBED 

The  simulation  testbed  was  configured  as  shown  in  figure  1 to  provide  an  ATC 
position  representing  an  oceanic  sector  and  a pilot's  position  simulating  an 
airborne  user.  Minicomputer  equipments,  displays,  and  Input/output  devices 
previously  used  in  support  of  the  Applications  Technology  Satellite  (ATS-6) 

ATC  demonstrations  (reference  1),  with  additional  hardware  and  software,  were 
utilized  to  develop  and  construct  the  simulation  testbed.  Table  1 lists 
these  equipments  and  their  nomenclatures,  and  figures  2 through  4 are  photo- 
graphs of  the  controller's  and  simulated  pilot's  positions  and  the  computer 
complex. 

CONTROLLER'S  POSITION.  As  indicated  in  figure  1,  the  controller's  position 
consisted  of  an  air  traffic  cathode  ray  tube  (CRT)  situation  display  with 
associated  function  key  panel,  a tabular  CRT  display  on  which  aircraft  flight 
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CSD  - CONTROLLER  SITUATION  DISPLAY 
CTD  - CONTROLLER  TABULAR  DISPLAY 
CFKP  - CONTROLLER  FUNCTION  KEY  PANEL 
TTY  - TELETYPE  TERMINAL 
CDCD  - CONTROLLER  DATA  COMMUNICATIONS  DISPLAY 
CDKB  - CONTROLLER  DATA  KEYBOARD 
QAK  - QUICK  ACTION  KEYS 

DCLTMP  - DATA  COMMUNICATIONS  LONG  TEXT  MESSAGE  PRINTER 
PDCD  - PILOTS  DATA  COMMUNICATIONS  DISPLAY 
PDKB  - PILOTS  DATA  KEYBOARD 

VC  - VOICE  COMMUNICATIONS  TERMINAL 


FIGURE  1. 


77-37-1 

BLOCK  DIAGRAM  OF  SATELLITE  SYSTEMS  CONFIGURATION/CHANNEL 
ACCESS  CONTROL  SIMULATION  TESTBED 
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plan  Information  was  shown  (figure  5),  and  a data  communication  CRT  display 
with  data  keyboard  and  quick  action  keys,  A teletype  terminal,  used  for  print- 
out of  message  format  errors,  a data  communication  long-text  message  printer,  and 
a headset  with  microphone  were  also  located  at  this  position.  The  situation  and 
tabular  displays  were  controlled  by  computer  "A",  while  the  data  communication 
display  and  long  text  message  printer  were  controlled  by  computer  "B". 

Computer  A,  The  software  In  computer  "A"  generated  an  oceanic  area  map 
(figure  6)  with  latitude  and  longitude  grid,  permanent  route  structures,  air- 
craft targets  with  projected  routes,  data  blocks,  leaders,  velocity  vectors, 
problem  time,  the  menu  selected  (a  choice  of  two),  conflict  and  late  alerts, 
and  verified  signals  for  display  on  the  situation  display.  The  software  also 
provided  capability  for  the  controller  to  manipulate  the  presentation  on  the 
display.  This  capability  was  accomplished  through  use  of  a special  keyboard, 
depicted  In  figure  7,  and  a light  pen.  The  latter  Item  functioned  similar 
to  the  track  ball  associated  with  the  National  Airspace  System's  (NAS)  radar 
controller  position. 

A description  of  the  situation  and  tabular  display  control  provisions  with 
their  associated  functions  Is  contained  In  appendix  A. 

Computer  B.  The  software  In  computer  "B"  controlled  the  data  and  voice 
communications  transactions  of  the  simulation  tests,  provided  the  time  delays, 
which  simulated  satellite  channel  access  delays,  and  generated  the  format  and 
message  presentation  for  the  data  communication  display.  Figure  8 shows  a 
typical  display  presentation  for  a simulation  test  that  featured  a choice  by 
the  controller  test  subject  of  voice  or  data  communications. 

Communications  between  computer  "A"  and  "B"  were  accomplished  through  a 
computer-to-computer  Interface  and  special  software.  These  software  provisions 
enabled  the  controller  to  use  the  data  keyboard  and  associated  communication 
display  to  enter  changes  In  flight  plans  and  Introduce  air  files  Into  the 
system  for  both  data  and  voice  communications  transactions. 

The  data  communication  display/control  provisions  and  associated  functions 
are  described  In  appendix  A. 

SIMULATED  PILOT'S  POSITION.  The  simulated  pilot's  position,  shown  In  figure  3 
consisted  of  a computer  terminal  display/keyboard  and  a headset  with  microphone. 
The  display/keyboard  unit  was  used  to  simulate  a cockpit  display  unit  (CDU)  I/O 
that  would  normally  be  utilized  by  a pilot  for  satellite  data  communication 
In  an  oceanic  environment.  The  actual  CDU,  located  In  the  aircraft's  cockpit, 
would  have  a design  more  compact  In  size  and  feature  a small  CRT  display  and  a 
keyboard  that  emphasizes  dedicated  function  keys. 

The  simulated  pilot's  display/control  provisions  and  associated  functions  are 
described  In  appendix  A. 

Voice  communication  transactions  between  the  ATC  test  subject  and  simulated 
pilots  positions  were  logged  for  posttest  analysis  by  a four-channel  magnetic 
tape  recorder.  The  recorder  was  remotely  operated  by  the  computer.  It  was 
turned  ON  when  the  computer  activated  a voice  channel  and  turned  OFF  when  the 
channel  was  deactivated. 
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FIGURE  6.  SIMULATION  TESTBED,  SITUATION  DISPLAY  SHOWING  OCEANIC  AREA  MAP 
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FIGURE  7.  SIMULATION  TESTBED,  SITUATION  AND  TABULAR  DISPLAYS  FUNCTION  KEYBOARD 
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FIGURE  8.  SIMULATION  TESTBED,  DATA  COMMUNICATIONS  DISPLAY  SHOWING  A TYPICAL  PRESENTATION 
FOR  A VOICE  AND  DATA  TEST 
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SIMULATION  TEST  DESIGN. 

t 

The  initial  step  In  the  simulation  design  for  the  SSC/CAC  tests  was  to  define 
the  characteristics  embodied  in  the  proposed  AEROSAT  system's  configurations 
and  channel  access  control  techniques  which  affect  the  system  user.  The  nature 
of  the  major  Impact  on  the  system  user  was  resolved  to  be  delays  in  channel 
access.  The  basic  contributors  to  channel  access  delay  were  determined  to  be 
the  number  of  channels  available,  the  number  of  aircraft  involved,  and  the 
method  of  access  and  control  being  used  in  the  satellite  communications  system. 
The  delays  could  be  very  short,  which  would  be  representative  of  a system  that 
has  many  channels  available,  and  the  usage  is  primarily  dedicated  to  data 
communication.  Delays  could  also  be  very  long,  as  in  a system  with  few 
channels  and  where  these  channels  are  essentially  used  for  voice  communication 
which  requires  substantially  more  on-channel  time  than  data  communication. 

Systems  management  and  the  techniques  employed  for  determining  who  will  use  a 
particular  channel  at  any  one  time  will  also  have  a significant  affect  on  delays. 
There  are  many  different  configurations  of  a satellite  communications  system 
that  can  produce  the  same  type  and  duration  of  delay.  In  the  subject  simulation 
design,  no  attempt  was  made  to  relate  different  time  delays  to  particular  system 
configurations.  In  most  cases,  the  delays  will  vary  over  certain  ranges  which 
can  be  represented  through  delay  curves.  These  curves  graphically  show  the 
minimum  and  maximum  time  delays  and  the  probability  of  occurrence  of  a partic- 
ular delay. 

There  were  two  types  of  delay  curves  used  in  the  simulation  tests,  flat  distri- 
bution and  Gaussian  distribution.  The  flat  delay  curve  provided  an  equal 
probability  of  getting  any  delay  between  the  minimum  and  the  maximum  values 
within  the  delay  range  defined.  For  example,  when  using  the  flat  delay  curve 
with  a range  of  5 to  25  seconds  delay,  there  was' an  equal  probability  of 
having  a 7-second  delay  as  a 13-  or  20-second  delay.  The  range  of  the  curve 
was  20  seconds  (5-25-20)  with  a mean  delay  value  of  15  seconds  (5+20«15) . 
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Therefore,  this  particular  delay  curve  was  referred  to  as  a 15-second  flat  delay 
curve.  Conversely,  the  Gaussian  delay  curve  resulted  in  a delay  distribution 
that  provided  a high  probability  for  having  a delay  which  approached  the  mean 
value  within  the  delay  range  defined.  Using  the  same  delay  range  of  5 to  25 
seconds  for  the  Gaussian  curve,  the  predicted  probability  of  having  a delay 
between  12  to  18  seconds,  for  example,  was  71  percent,  while  the  probability 
of  having  a delay  of  5 or  25  seconds,  the  extremes  of  the  delay  range,  was  less 
than  10  percent.  The  delay  value  with  the  highest  probability  of  occurring  was 
the  mean  value  or  as  in  this  example,  15  seconds. 

In  the  SSC/CAC  simulation  testbed,  the  methods  used  to  obtain  the  flat  and 
Gaussian  delay  periods  applied  in  the  individual  tests  was  a pseudorandom 
selection  of  a delay  value  from  a table  of  discrete  delay  periods.  The  table 
consisted  of  64  slots,  each  containing  a delay  period  value  derived  from  pre- 
determined flat  or  Gaussian  delay  curves.  Through  utilization  of  the  high- 
speed, real-time  clock  in  computer  "B"  incrementing  a 1 to  64  counter  and  by 
employing  a nonperiodic  slow  sampling  of  the  couyter  output,  a pseudorandom 
number  generator  was  Implemented.  When  a delay  period  was  required  during  a 
test,  a random  number  from  1 to  64  was  generated,  and  that  number  was  used  to 
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Indicate  which  slot  of  the  64  slots  In  the  delay  table  was  to  be  used.  This 
method  of  choosing  the  delay  period  ensured  that  each  slot  In  the  delay  table 
had  an  equal  probability  of  being  selected;  therefore,  It  was  directly  applicable 
for  providing  the  flat  delay  curve  delays.  Gaussian  delay  curve  delays  were 
provided  by  placing  the  higher  probability  delay  values  In  multiple  slots  In 
the  delay  table  and  the  lower  probability  values  In  fewer  slots  In  the  table. 

The  delay  curves  with  their  respective  range  of  delay  values  used  for  the  SSC/ 

CAC  simulation  tests  are  listed  In  table  2. 


TABLE  2.  SSC /CAC  SIMULATION  TESTS  DELAY  CURVES 


Delay  Curve/Type 

30  Seconds  Flat 
45  Seconds  Flat 
60  Seconds  Flat 

30  Seconds  Gaussian 
45  Seconds  Gaussian 


Range  of  Delay  Values 

15  to  46  seconds 
13  to  76  seconds 
25  to  88  seconds 

5 to  68  seconds 
7 to  90  seconds 


A third  type  of  delay  used  In  the  subject  simulation  tests  was  a fixed  5-second 
delay  used  for  all  short-text  data  communications  messages.  The  5-second 
delay  was  selected  to  represent  the  minimum  time  period  required  for  acquisition 
of  a channel  and  synchronization,  or  lock-up,  of  the  satellite  system's  ground 
and  airborne  terminals  digital  communications  equipments. 

The  next  step  In  the  simulation  design  was  to  develop  an  air  traffic  scenario 
for  use  in  the  Individual  test  runs.  Three  traffic  samples  consisting  of 
15  aircraft  and  associated  flight  plans  (appendix  B)  were  prepared.  The  air- 
craft's flightpaths  were  arranged  to  reflect  current  oceanic  separation  stan- 
dards. (In  brief,  these  standards  require  120  nautical  miles  (nml)  lateral 
spacing  of  aircraft,  20  minutes  flying  time  separation  in  longitude,  1,000  feet 
vertical  separation  up  to  and  Including  29,000  feet  altitude,  and  2,000  feet 
vertical  separation  above  an  altitude  of  29,000  feet.)  Six  scripts  (appendix  B) 
associated  with  the  aircraft  in  the  three  flight  plans  were  prepared.  These 
scripts  contained  communications  cues  for  the  controller  test  subject  and  simu- 
lated pilot.  At  appropriate  points  in  the  aircraft's  flight,  communication 
transactions  were  identified  for  Initiation  by  either  the  controller  test 
subject  or  the  simulated  pilot.  Some  of  the  communication  transactions, 
depending  upon  the  actual  traffic  situation  In  the  simulation  run  at  that  time, 
could  necessitate  several  exchanges  between  the  controller  and  simulated  pilot. 

There  were  10  test  runs  designed  Into  the  simulation  tests:  two  voice-only, 
two  data-only,  and  six  choices  of  data  or  voice;  the  latter,  the  choice  of  data 
or  voice,  was  at  the  discretion  of  the  controller  test  subject.  The  three 
traffic  samples  and  associated  scripts  described  above  were  used  Interchangeably 
for  the  three  types  of  test  runs.  Data  communication  test  runs  were  divided 
Into  three  levels  of  message  constraints  for  the  purpose  of  simulating  three 
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different  kinds  of  I/O  capability  In  the  AEROSAT  user  aircraft  cockpit. 

These  constraints  were:  Level  1 - unconstrained  In  length  of  message  and  type 
of  format  used  (assumption:  user  aircraft  has  a computer-type  display/ 
keyboard  I/O  device) , Level  2 - constrained  In  length  of  message  used  to 
16  characters,  excluding  the  aircraft  Identification  and  quick  action  function 
Identifier  symbol  (assumption:  user  aircraft  has  a limited  window  display 
capability  of  16  characters  and  alphanumeric  keyboard  I/O  device),  and 
Level  3 - constrained  to  the  use  of  fixed  format  messages  that  were  acceptable 
In  format  for  computer  processing  (assumption:  user  aircraft  has  a limited 
window  display  capability  of  16  characters  and  dedicated  function  button 
I/O  device) . 

Figure  9 presents  a listing  of  the  test  parameters  associated  with  the  10 
simulation  test  runs.  The  SSC/CAC  test  schedule  was  arranged  to  accommodate 
10  ATC  test  subjects;  however,  due  to  a conflict  In  availability,  only  9 test 
subjects  actually  participated  In  the  data  collection  runs.  Each  test  subject 
was  assigned  to  a 2-week  effort,  1-week  for  brief Ing/tralnlng  and  1 week  for 
the  actual  tests.  During  the  first  week,  the  test  subject  was  briefed  on  the 
test  details,  operation  of  the  equipment  at  the  testbed  controller's  position, 
and  familiarization  with  the  traffic  samples  and  test  area  geography. 

Conduct  of  the  Individual  test  runs  required  four  participants:  testbed  operator, 
simulated  pilot,  test  observer,  and  test  subject.  The  duties  of  these  partici- 
pants were  as  follows: 

Testbed  Operator  - Turn  ON  testbed  equipment,  checkout  system,  bring  up  proper 
traffic  sample,  set  in  delay  factor,  monitor  run  for  system  malfunctions,  and 
set  up  voice  recording  equipment. 

Simulated  Pilot  - Checkout  simulated  pilot's  position  equipment,  confirm  use 
of  proper  flight  plan  and  associated  script,  confirm  test  run  parameters, 
checkout  communications'  channel  If  test  run  Is  a voice-only  or  choice  of  voice 
or  data,  and  operate  the  simulated  pilot's  position  In  accordance  with  the 
test  scenarios. 


Test  Observer  - Confirm  that  all  testbed  equipment  is  ON  and  functioning 
properly,  confirm  that  the  proper  traffic  sample  and  associated  script  Is  being 
used  for  the  test  run  and  that  the  appropriate  delay  parameter  has  been  set 
Into  the  computer,  distribute  the  test  run  script  and  flight  plan,  brief 
controller  test  subjects  on  the  type  of  test  run  and  the  test  parameters, 
make  entries  of  all  applicable  data  on  observer's  log,  start  test  run,  record 
time,  monitor  test  run  and  cue  test  subject  on  ATC-initiated  actions  as 
required,  log  all  occurrences  that  may  have  a bearing  on  the  data,  end  test 
run  when  all  Items  on  the  script  are  completed,  log  type  number  on  voice 
recording  for  applicable  test  runs,  gather  together  and  label  all  hard  copy 
data  logs  from  the  high-speed  printer  and  long  text  printer,  debrief  test 
subject,  log  comments,  brief  test  subject  on  next  test  run,  administer  prepared 
questionnaires  to  test  subjects  as  required,  and  maintain  the  Integrity  of 
the  data  package  for  posttest  analysis. 
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SSC/CAC  SIMULATION  TEST  PARAMETERS 


Run 

Sample 

Run 

Delay 

Test 

Number 

Number 

Type 

Shape 

Constraints 

1 

2 

VOICE 

45 

SEC 

FLAT 

NOT  APPLICABLE 

2 

2A 

DATA 

30 

SEC 

FLAT 

(LONG) 

UNCONSTRAINED  IN 

5 

SEC 

FLAT 

(SHORT) 

MESSAGE  LENGTH  & 

FORMAT 

3 

3 

CHOICE 

30 

SEC 

G (VOICE) 

FIXED  FORMAT 

V or  D 

5 

SEC 

FLAT 

(DATA) 

4 

3A 

CHOICE 

45 

SEC 

G (VOICE) 

ONE  LINE  LIMIT 

V or  D 

5 

SEC 

FLAT 

(DATA) 

(16  CHARACTERS) 

5 

1 

CHOICE 

45 

SEC 

FLAT 

(VOICE) 

UNCONSTRAINED  IN 

MESSAGE 

V or  D 

5 

SEC 

FLAT 

(DATA) 

LENGTH  & FORMAT 

6 

lA 

VOICE 

45 

SEC 

G 

NOT  APPLICABLE 

7 

2 

DATA 

30 

SEC 

FLAT 

(LONG) 

UNCONSTRAINED 

5 

SEC 

FLAT 

(SHORT) 

8 

2A 

CHOICE 

30 

SEC 

FLAT 

(VOICE) 

FIXED  FORMAT 

V or  D 

5 

SEC 

FLAT 

(DATA) 

9 

3 

CHOICE 

45 

SEC 

FLAT 

(VOICE) 

ONE  LINE  LIMIT 

V or  D 

5 

SEC 

FLAT 

(DATA) 

(16  CHARACTERS) 

10 

3A 

CHOICE 

60 

SEC 

FLAT 

(VOICE) 

UNCONSTRAINED  IN 

MESSAGE 

V or  D 

5 

SEC 

FLAT 

(DATA) 

LENGTH  & FORMAT 

Notes:  V = VOICE 
D = DATA 

G = GAUSSIAN  DELAY  CURVE 


FIGURE  9.  TEST  PARAMETERS  USED  IN  THE  10  SSC/CAC  SIMULATION  TEST  RUNS 
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Test  Subject  - Learn  test  area  geography,  become  familiar  with  operation  of 
equipment  in  the  testbed  controller's  position  and  the  traffic  samples,  know 
what  the  test  subject  duties  are,  respond  to  return  channel  communications  and 
initiate  forward  channel  communications  on  cue,  observe  test  parameter 
restraints  during  test  runs,  and  provide  test  run  comments  to  test  observer. 

A typical  simulation  test  run  progressed  as  follows:  the  test  observer  deter- 
mined that  the  testbed  was  in  a ready  status  for  conduct  of  the  test.  The 
controller  test  subject,  using  the  displayed  video  map  (figure  6)  and  the 
assigned  traffic  sample,  would  initiate  action  through  the  "freeze/resume" 
key  on  the  function  key  panel  (FKP) . Normally,  the  controller  would  first 
choose  the  area  to  be  displayed  by  the  FKP  "area"  key  and  then  activate  the 
"zoom"  key  once  to  enlarge  the  central  portion  of  his  operation  area.  At  this 
point,  the  script  was  implemented  in  the  test  run.  The  script  contained  14 
separate  action  cues,  10  of  which  were  initiated  by  the  simulated  pilot  and 
the  remaining  4 initiated  by  the  controller  test  subject.  The  script  was 
faithfully  followed  until  all  items  were  completed.  No  action  item  was 
commenced  until  the  previous  one  was  concluded.  Over  and  above  the  script 
items,  ATC  conflicts  could  occur  during  a test  run.  When  conflicts  did  occur, 
they  were  signaled  to  the  controller  who  was  expected  to  resolve  them  before 
proceeding  to  the  next  script  item.  The  test  run  required  30  to  45  minutes 
to  complete,  depending  upon  the  Imposed  test  constraints.  Upon  completion  of 
the  test  run  the  controller  test  subject  was  debriefed  by  the  test  observer, 
and  the  data  logs  from  the  high-speed  printer,  long  text  message  printer,  voice 
channel  magnetic  tape  recordings,  and  observer  notes  were  collected  and  stored 
as  a discrete  data  package  for  posttest  data  analysis. 

A general  questionnaire  on  the  SSC/CAC  tests  was  administered  to  each  controller 
test  subject  upon  completion  of  the  5th  test  run  and  again  upon  completion  of 
the  10th  test  run.  Additionally,  a questionnaire  on  the  CRD  was  administered 
to  each  test  subject  after  completion  of  the  10th  test  run.  Copies  of  these 
questionnaires  are  contained  in  appendix  B. 


TEST  RESULTS 


The  SSC/CAC  tests  results  were  derived  from  several  sources:  test  subject 
opinions  and  comments  via  the  questionnaires,  test  observer  notes,  and  the 
data  and  voice  communications  logs. 

GENERAL  QUESTIONNAIRE. 

The  results  of  the  general  questionnaire  are  addressed  in  the  following 
discussions: 


a.  In  voice-only  communication  tests,  the  majority  of  the  test  subjects 
indicated  that  the  waiting  times  for  the  channel  were  acceptable,  no  matter 
which  delay  factor  was  used  in  the  test  runs. 

|j 
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b.  In  "choice"  tests,  where  either  voice  or  data  communication  was 
available,  all  but  one  of  the  nine  test  subjects  favored  use  of  the  data  channel 
over  the  voice  channel. 

c.  The  voice  channel  was  preferred  by  six  of  nine  test  subjects  as  the 
most  expedient  means  for  resolving  difficult  control  situations. 

d.  All  test  subjects  Indicated  that  they  believed,  from  their  experiences 
In  the  tests,  that  the  voice  channel  would  be  used  less  than  25  percent  of 

the  time  In  a similar  design  real  life  system  for  oceanic  ATC. 

e.  The  test  subjects  were  In  agreement  that  the  types  of  messages 
provided  through  the  computer  message  Identifier  quick  action  keys  and  the 
restricted  format  messages  used  In  the  data  communication  tests  were  sufficient 
In  scope  and  acceptable  to  them  as  a satisfactory  means  for  all  of  the  ATC 
functions  they  would  require  In  an  oceanic  environment.  In  their  answers  to 
the  questions  relating  to  message  types  and  formats  for  data  communication, 

the  test  subjects  had  the  following  comments:  two  of  the  message  formats  that  | 

were  especially  useful  for  the  data  communication  mode  were  altitude/speed  ’ 

changes;  however,  they  suggested  that  there  should  be  a more  positive  dlfferen-  i 

tlatlon  of  the  two  than  simply  an  "S"  In  the  speed  change  format  of  the  message.  ! 

In  the  tests,  speed  change  messages  were  Inadvertently  sent  without  the  "S," 
with  the  result  of  having  altitudes  changed  to  the  requested  speed.  Although 
an  In-alr  reroute  was  easily  entered  by  means  of  the  "AT"  message,  most  test 
subjects  felt  that  an  "RR"  message  Identifier  would  enhance  operations,  but 
was  not  an  essential  Item.  The  flight  plan  format  was  acceptable  to  the  test 
subjects,  but  believed  by  some  to  be  cumbersome  and  difficult  to  remember  as 
evidenced  In  the  fact  that  they  were  not  totally  familiar  with  It  until  late 
In  the  data  communication  test  runs.  Some  test  subjects  had  difficulty  remem- 
bering to  accomplish  the  mechanical  function  of  activating  the  "accept"  or 
"reject"  control  provision  function  key  after  entry  of  a position  report.  The 
position  report  and  hold  messages  were  considered  to  be  straightforward  and 
easily  entered.  In  the  reception  of  pllot-lnltlated  messages,  the  test  subjects 
suggested  that  a standard  format  for  a "Pilot's  Report"  (PIREP)  would  be  a 
useful  feature. 

f.  Test  subjects  were  about  equally  divided  In  their  response  to  the 
question  of  whether  they  were  forced  to  use  the  voice  channel  more  than  they 
actually  wanted  to  when  test  restraints  were  placed  on  the  length  of  data 
communication  messages. 

g.  When  asked  to  compare  data  to  voice  communication  In  the  first 
administered  questionnaire,  seven  of  the  nine  test  subjects  Indicated  that 
they  would  rather  use  data  than  voice;  the  remaining  two  Indicated  that  data 
communication  could  be  used  to  supplement  voice.  On  the  second  administered 
questionnaire,  all  test  subjects  Indicated  that  they  would  rather  use  data 
than  voice  communication,  but  three  of  them  also  Indicated  that  In  some  ATC 
situations  data-supplemented  voice  communication  would  be  their  choice. 
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h.  The  question  of  what  the  test  subjects  considered  to  be  prominent 
features  of  the  simulated  oceanic  ATC  satellite  communications'  system  elicited 
the  following  responses:  The  situation  display  met  with  unanimous  approval,  but 
the  displays  of  tabular  Information  were  criticized  for  containing  too  much 
Information.  The  positive  communication  feature  of  the  data  channel  and 
availability  of  a direct  voice  channel  were  considered  to  be  a quantum 
Improvement  over  current  oceanic  communications  capabilities.  In  connection 
with  the  availability  of  a voice  channel,  it  was  thought  that  there  should  be 
a means  of  immediate  contact  of  a particular  aircraft  or  the  preempting  of  a 
channel  in  use  to  deliver  an  Imperative  message  and  also  provisions  for  simul- 
taneously transmitting  an  advisory  to  all  aircraft  In  a particular  sector. 

The  automatic  conflict  alert  provision  was  cc  sldered  to  be  a good  feature; 
however,  some  test  subjects  thought  that  at  times  alerts  were  activated 
(flashed  on  the  display)  too  much  in  advance  of  conflicts.  It  was  suggested 
that  the  system  should  provide  the  controller  with  alternate  courses  of  action 
to  resolve  the  conflicts,  such  as  available  free  altitudes  or  route  changes. 

The  provision  of  dependent  or  Independent  surveillance  was  recognized  as 
an  Immediate  means  for  reducing  oceanic  separation  standards  and  thus  ensuring 
more  efficient  use  of  oceanic  airspace  and  accommodation  of  large  traffic 
volumes.  In  addition  to  the  CRD  being  used  as  the  data  communications  I/O, 

It  was  suggested  that  this  device  would  serve  as  an  excellent  replacement  for 
flight  strips.  To  accommodate  this  application,  computer  storage  of  ground/ 
air  and  air /ground  messages,  at  least  for  the  period  of  time  the  aircraft  was 
in  the  sector,  would  need  to  be  provided.  It  was  noted  that  during  the 
transition  of  an  aircraft  through  his  sector,  a controller  may  need  to  refer 
to  a message  previously  sent  to  or  received  from  an  aircraft.  The  controller 
could  have  this  option  through  the  utilization  of  a message  storage  bank. 

Message  storage  would  also  eliminate  loss  of  data  due  to  an  overloaded  CRD. 
Additionally,  if  message  storage  could  be  retained  for  periods  up  to  24  hours, 
this  feature  could  also  be  used  for  traffic  counts  much  like  the  use  of  flight 
strips  for  this  purpose  in  current  domestic  operations. 

TEST  SUBJECT  COMMENTS  ON  SITUATION  DISPLAY  AND  CONTROL  FUNCTIONS. 

The  test  subjects  were  quite  impressed  with  the  situation  display  and  con- 
sidered it  one  of  the  key  features  of  the  simulation  testbed.  Their  use  of 
the  display  and  associated  control  function  keys,  as  noted  by  the  test  observer 
and  recounted  from  their  comments  obtained  during  the  debriefings,  are  presented 
in  the  following  discussions  under  headings  related  to  certain  control 
provisions. 

FULL  DATA  BLOCK.  This  control  provision  and  associated  menu  list  was  selected 
most  often  by  the  test  subjects  to  remain  displayed  during  the  test  run.  It 
provided  the  means  for  the  controller  to  offset  data  blocks  around  the  target 
symbol  and  to  control  the  size  of  the  alphanumeric  characters.  In  its  use  for 
character  size  adjustment,  the  next-to-the-smallest  size  setting  was  the  one 
most  universally  used  by  the  test  subjects.  The  offset  feature  of  this  menu 
was  the  one  most  frequently  used,  whereas  the  delete  data  block  feature  was 
never  used  by  the  test  subjects  during  the  test  runs.  In  the  use  of  this  menu 
list,  the  requirement  to  terminate  the  manipulation  of  the  list  items  was 
alerted  to  the  controller  by  the  appearance  of  "end  select"  at  the  bottom  of 
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the  data  block.  This  alert  was  very  easily  overlooked  by  the  test  subjects  and  | 

was  considered  to  add  another  unneeded  step  to  what  should  be  a simple  feature.  t 

It  was  suggested  by  some  test  subjects  that  a provision  for  offsetting  the  data 
blocks  through  a keyboard  entry,  as  well  as  the  light  pen  and  associated  menu 
list,  would  be  an  enhancement  option  for  the  simulation  testbed.  j 

AREA  DISPLAY.  REVISE  MAP,  END  REVISE  MAP.  These  control  provisions  actually  i 

were  not  utilized  by  the  test  subjects  during  the  test  runs;  apparently,  j 

because  they  found  no  real  need  to  employ  them.  In  simulation  scenarios 
wherein  separate  voice  and  data  communications  controllers  are  used  to  man  the 
position,  the  requirement  to  use  these  control  features  would  be  more  evident 
to  the  controller  handling  surveillance  (similar  to  the  NAS  radar  controller 
position) . 

WINDOW-NORTH /SOUTH /EAST /WEST.  These  control  provisions  were  used  primarily 
during  rerouting  operations  to  select  routes.  The  utilization  of  these  controls 
increased  with  the  test  subjects  experience  with  the  system.  Once  the  window 
concept  was  assimilated  these  control  features  became  more  useful.  This  was  a 
concept  that  was  more  easily  understood  through  demonstration  than  briefing. 

POSITION  VECTOR.  This  control  provision  was  not  manipulated  to  any  extent  by 
the  test  subjects.  Normally,  it  was  set  to  20  minutes  of  future  track  at  the 
I beginning  of  a test  run  and  allowed  to  remain  at  that  setting  throughout  the 

run. 

ROUTE/FLIGHT  TEVEL  FILTER.  This  control  provision,  which  was  available  to  the 
controller  for  deleting  selected  aircraft  targets  by  flight  level,  was  not  used 
by  the  test  subjects  during  the  test  runs,  since  only  one  ATC  sector  was 
involved  in  the  simulation  scenario. 

FLIGHT  PLAN  ROUTE  DISPLAY.  This  control  provision,  which  was  available  to  the 
controller  for  displaying  aircraft  flight  tracks  to  destination  and  was  particu- 
larly useful  in  conflict  situations,  was  seldom  used  in  the  test  runs  by  the 
test  subjects.  The  conflict  alerts  were  provided  well  in  advance  of  the  actual 
conflict;  in  some  instances,  as  much  as  1 hour  of  flight  time.  After  initial 
test  runs  demonstrated  to  the  controllers  that  invariably  the  projected  flight- 
paths  did  indeed  cross  at  the  altitude  being  flown  by  each  aircraft  in  the  con- 
flict situation,  the  controllers  accepted  with  a high  level  of  confidence  that 
the  computer  program  for  conflict  alerts  was  very  dependable.  Once  so  convinced, 
the  controllers  thereafter  would  simply  resolve  the  potential  conflict  at  the 
time  it  was  alerted  to  them.  This  procedure  on  the  part  of  the  test  subjects 
is  considered  to  be  unrealistic  for  an  actual  live  situation,  since  each 
controller  will  exercise  his  own  technique  in  dealing  with  a potential  conflict 
situation.  Although  alerts  for  an  oceanic  environment  would  be  programmed  to 
occur  30  minutes  in  advance  of  a conflict,  false  alerts  could  occur  earlier 
than  that.  Some  controllers  will  take  immediate  action,  while  others  will  defeat 
the  early  alert  and  wait  for  the  alert  that  is  within  the  prescribed  minimum 
time  period. 

MAP  FILTER.  This  control  provision  which  enabled  the  controller  to  manipulate 
the  map  presentation  was  not  used  by  the  test  subjects  during  the  test  runs 
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because  the  size  of  the  traffic  sample  used  In  the  simulation  scenario  was  not 
large  enough  to  clutter  up  the  map  presentation;  therefore,  there  was  no  urgent 
requirement  for  filtering  the  map  s}nnbology. 

ACCEPT/REJECT  ALTITUDE/FLIGHT  PLAN.  These  control  provisions  were  the  means 
for  the  controller  to  accept  or  reject  outputs  of  computer-derived  probes  of 
altitudes,  airspeeds,  and  conflict  alerts  concerning  flights  within  his  sector 
air  space.  It  was  noted  this  testbed  feature  showed  the  resourcefulness 
of  controllers  for  finding  a way  to  reduce  their  workload.  During  "choice" 
(voice  or  data  communication)  runs  and  data-only  runs,  the  test  subjects 
automatically  rejected  all  probes  (clearances  and  conflicts)  through  the  "Reject 
Altitude"  control  provision,  and  in  lieu  of  this  method  for  updating,  the 
computer  sent  the  cleared  altitude  or  airspeed  change  by  a data  communication 
"AT"  message  which  appeared  at  the  simulated  pilot  position  display  and  updated 
the  computer  at  the  same  time.  When  voice-only  runs  were  in  progress,  the 
simplest  way  to  update  the  computer  in  response  to  a requested  change  In  a 
flight  plan  was  to  utilize  the  "Accept  Altitude"  control  provision.  To  use 
the  data  communication  "AT"  message  technique  as  described  above  for  updating 
the  computer  would  be  an  unneeded  operation,  since  the  controller  would  have 
to  advise  the  simulated  pilot  of  the  clearance  through  the  voice  channel  anyway. 
It  was  noted  that  often  test  subjects  would  forget  to  accept  or  reject  probes 
and  this  tied  up  the  function  keyboard  so  that  no  other  control  provision  could 
be  used.  Activation  of  either  the  "Accept"  or  "Reject  Altitude/Flight  Plan" 
function  key  was  necessary  to  terminate  each  probe  and  allow  activation  of 
another  desired  control  provision.  It  was  the  general  opinion  of  the  test 
subjects  and  observer  that  this  control  provision  would  not  be  realistic  for 
use  in  a real  environment.  The  controller,  before  granting  an  altitude  change 
request,  would  need  to  determine  if  the  altitudes  above  or  below  the  altitude 
being  maintained  by  the  aircraft  requesting  the  change  were  occupied  by  other 
flights,  since  the  subject  aircraft  would  have  to  climb  or  descend  through  these 
altitudes.  If  the  probe  would  provide  data  on  free  altitudes,  rather  than  just 
the  altitude  probed  with  added  data  on  restrictions  where  intermediate  altitudes 
were  occupied,  the  control  provision  would  be  more  realistic. 

TAB/SITUATION  DISPLAY.  This  control  provision  enabled  the  controller  to  move 
either  the  "situation"  or  "tabular"  presentation  being  displayed  from  one 
display  unit  to  the  other.  Although  its  function  seemed  to  be  straightforward, 
it  caused  problems  for  some  test  subjects.  Apparently  the  problem  was  related 
to  the  fact  that  the  tabular  data  presentation  displayed  could  be  either  the 
selected  flight  plan  or  enroute  flight  plan  data;  the  selection  of  which  was 
controlled  by  another  control  provision,  the  "Selected  Flight  Plan"  function 
key.  Often  a test  subject  would  forget  which  tabular  presentation  had  been 
selected;  therefore,  when  he  moved  the  tabular  display  presentation  onto  the 
display  unit  he  was  viewing,  he  sometimes  became  confused  when  it  was  not  the 
presentation  he  was  expecting.  This  problem  was  attributed  to  unfamiliarity 
with  the  control  provisions  on  the  part  of  some  test  subjects,  and  it  is  expec- 
ted that  it  would  be  readily  resolved  with  sufficient  experience. 

SELECTED  FLIGHT  PLANS.  This  control  provision  was  available  to  the  controller 
to  call  up  onto  the  tabular  display  the  menu  of  all  ACID's  in  his  controlled 
airspace  for  which  the  selected  (filed)  flight  plan  data  of  each  aircraft  could 
be  displayed  through  activation  of  the  light  pen.  This  particular  tabular  pre- 
sentation was  not  extensively  used  by  the  test  subjects  during  the  test  runs. 
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ENROUTE  DATA  FLIGHT  PLANS.  This  control  provision,  similar  in  function  to  the 
above  "Selected  Flight  Plans"  provision,  provided  the  controller  with  the  dynamic 
flight  plan  data  on  each  aircraft  under  his  control.  This  tabular  display 
presentation  was  the  one  most  frequently  used  by  the  test  subjects.  Test 
subjects  indicated  that  it  was  difficult  at  times  to  pick  out  Individual  bits 
of  information  for  an  aircraft  halfway  down  the  10  or  so  columns  of  data  dis- 
played. It  was  suggested  that  the  use  of  this  display  could  be  enhanced  by 
Inserted  computer-generated  lines  between  each  two  lines  of  data,  or  pulsating 
brightness  of  the  particular  data  of  Interest.  The  latter-suggested  modifica- 
tion would  require  the  entering  of  some  kind  of  computer  message,  probably  an 
ACID  and  associated  special  character,  through  the  I/O  keyboard  in  order  to 
designate  which  flight  plan  data  were  the  data  of  interest. 

ACCEPT/REJECT  PROGRESS  REPORT.  These  two  control  provisions  were  available  to 
the  controller  in  connection  with  his  manual  entering  of  an  aircraft  flight 
progress  report.  If  the  entered  data  did  not  agree  with  the  computer-generated 
data,  an  alert  indicating  a disagreement  in  data  and  the  need  for  a verification 
was  given  the  controller.  This  alert  took  the  form  of  a flashing  "V"  next  to 
the  aircraft  track  symbol  on  the  situation  display  and  also  by  the  flashing  of 
the  erroneous  data  in  the  enroute  data  tabular  display.  By  the  activation  of 
either  of  these  two  control  function  keys,  the  controller  either  accepted  or 
rejected  the  computer  alert  and  took  the  appropriate  follow-on  action.  During 
the  test  runs,  if  the  test  subject  was  viewing  the  situation  display  and  not 
paying  attention  to  the  enroute  data  tabular  display  or  busying  himself  with 
operations  at  the  data  communication  position,  he  often  overlooked  the  alert  on 
the  situation  display.  This  problem  was  attributed  to  inexperience  on  the  part 
of  the  test  subject  in  the  proper  use  of  the  different  displays  and  an  artificial 
simulated  oceanic  ATC  environment;  the  latter  because  the  test  subject  was 
manning  both  the  "S"  (surveillance)  and  "D"  (data)  positions.  In  real  life, 
there  would  be  a separate  controller  for  each  position. 

COMPUTER  READOUT  DEVICE  QUESTIONNAIRE. 

The  following  discussion  summarizes  the  results  of  the  questionnaire  on  the 
CRD. 

All  test  subjects  were  of  the  opinion  that  the  information  capable  of  being 
displayed  on  the  CRD,  the  size  of  the  preview  and  the  computer  areas,  the 
functions  provided  by  the  quick-action  keys,  and  the  methods  for  deleting  data 
were  of  good  design.  They  also  indicated  that  the  overall  use  of  the  CRD  for 
ground-air-ground  data  communication  was  acceptable  to  them.  A number  of  test 
subjects  had  suggestions  for  improvements  which  they  thought  would  be  bene- 
ficial to  the  "D"  position  of  the  simulation  testbed;  these  were: 

a.  The  ability  to  identify  the  receiving  aircraft  for  dispatch  of  a 
message  by  other  means  than  typing  in  an  ACID,  such  as  a track-ball. 

b.  Provision  to  alert  the  controller  of  a potential  data  overflow  in 
the  computer  area  of  the  CRD  and  the  capability  for  storage  of  the  overflow 
data  for  future  recall. 
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c.  Provision  for  the  controller  to  have  an  option  for  using  or  defeating 
the  automatic  ACID  feature  to  prevent  its  confusing  him.  Some  test  subjects 
found  this  feature  helpful  to  them,  others  indicated  it  was  causing  them 
added  workload. 

d.  An  Increase  in  the  display  time  for  the  special  alert  symbols 
associated  with  aircraft  reply  messages  displayed  in  the  computer  area  of  the 
CRD.  The  display  time  designed  into  this  feature  was  15  seconds,  which 
seemed  to  be  adequate;  however,  it  is  not  a critical  item  and  can  be  adjusted 
to  whatever  period  is  determined  to  be  optimum. 

TEST  OBSERVER  COMMENTS. 


The  test  observer  notes  concerning  general  comments  on  the  simulation  tests 
and  the  testbed  are  summarized  in  the  following  discussions: 

a.  Data  communication  was  preferred  over  voice  communication  by  the  test 
subjects  primarily  for  two  reasons,  delays  in  obtaining  a voice  channel  and 
because  the  computer  flight  plan  information  was  updated  automatically  by  the 
data  message.  Another  advantage  noted  was  that  data  communication  would  provide 
a positive  transfer  of  control  instructions  to  pilots  of  foreign  flag  carriers 
whose  national  language  is  not  English,  viz.,  printed  data  are  more  intelligible 
than  spoken  word. 

b.  The  fixed  reroute  message  format  used  in  the  tests  did  not  provide 
for  inclusion  of  an  altitude.  It  was  the  opinion  of  all  test  subjects  that  an 
altitude  should  be  specified  in  the  message  to  preclude  the  necessity  of  having 
to  accomplish  the  added  operation  of  updating  the  computer-stored  altitude  in 
the  event  the  controller  had  to  change  the  aircraft  assigned  altitude. 

c.  It  was  observed  that  most  test  subjects  could  cope  with  the  limited 
length  message  (16  characters)  constraint  by  judicious  use  of  abbreviations. 

This  would  suggest  that  a standardized  list  of  abbreviations  and  control 
symbols  would  be  a beneficial  feature  for  a real-time  oceanic  system. 

d.  Another  observation  concerned  controller  techniques  when  replying  to 
an  altitude  change  request  via  data  communication.  Some  test  subjects  simply 
replied  with  a message  containing  a dif ferent-than-requested  altitude  without 
any  advice  to  the  pilot  that  his  requested  altitude  was  unavailable.  Other 
controllers  would  return  a message  that  indicated  they  were  unable  to  provide 
the  requested  altitude  and  were  offering  an  alternate  altitude  for  the  pilot's 
concurrence;  for  example,  "Unable  290  OK  310."  If  there  were  no  alternate 
altitudes  available,  the  message  would  be,  "Unable  290  remain  at  270."  This 
procedure  avoided  uncertainty  on  the  pilot's  part;  otherwise  he  might  conclude 
that  the  controller  gave  him  the  wrong  requested  altitude  due  to  a garble  in 
his  air-to-ground  message. 

DATA  RECORDS/LOGS  ANALYSIS. 

One  of  the  objectives  of  the  SSC/CAC  tests  was  to  determine  from  analysis  of 
the  data  and  voice  communications  logs  answers  to  such  questions  as: 
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a.  What  was  the  mix  of  voice  and  data  communication  messages  In  the 
simulated  satellite-communlcations-supported  oceanic  ATC  environment? 

b.  What  was  the  merit  of  the  design  of  the  data  communication  "Quick 
Action  Keys"  configuration? 

c.  Did  the  controller  test  subjects  resort  to  use  of  abbreviations  to 
expedite  data  communication  exchanges  during  test  runs  which  were  restricted 
to  the  free  format  mode? 

d.  Was  there  a need  to  redesign  the  fixed  format  messages  used  in  the  j 

data  communication  tests?  ■ 

e.  Was  there  a need  for  lengthening  the  selected  short  text  message  length 
used  in  the  data  communication  tests? 

The  answers  to  the  above  questions  are  addressed  in  the  following  discussions. 

The  simulation  test  runs  that  featured  a choice  for  the  controller  test  subjects 
between  voice  and  data  communication  were  used  in  the  analysis  to  determine  the 
mix  of  voice  and  data  communication  that  might  be  expected  in  an  ATC  oceanic 
environment  supported  by  satellites.  The  results  of  the  analysis  showed  that 
there  were  74-percent  data  and  26-percent  voice  messages  or  a ratio  of  3 to  1 
in  the  use  of  data  communication. 

The  analysis  of  the  merits  of  the  design  of  the  "Quick  Action  Key"  configura- 
tion revealed  that  most  of  the  message  provisions  selected  for  the  single-key 
entry  were  a good  decision.  Utilization  of  the  different  quick  action  message 
provisions  were  governed  to  a certain  degree  by  the  design  of  the  test  scenar- 
ios. The  most-used  "Quick  Action  Keys"  were  the  "Probe"  and  "Transmit"  message 
functions  followed  by  "Flight  Plan",  "Activate  Flight  Plan",  "Progress  Report", 

"Delete  Data",  "Hold/Delay",  and  "Cancel."  By  design,  "Request  Voice"  and  "End  • 

Voice"  keys  were  required  to  be  used  for  all  voice  communication  transactions;  | 

therefore  their  utilization  rate  was  high  as  expected.  * 

A review  of  the  data  logs  for  the  test  runs  devoted  to  free  format  messages 
did  not  reveal  any  action  on  the  part  of  the  controller  test  subject  to  resort 
to  abbreviations  to  expedite  data  communication  transactions.  It  should  be 
noted  that  when  the  test  subjects  were  briefed  on  the  simulation  tests,  they 
were  given  a suggested  list  of  12  abbreviations  (appendix  B)  for  use  in  compos- 
ing data  messages.  These  abbreviations  were  used  extensively  in  the  fixed 
format  as  well  as  the  unconstrained  format  tests.  Therefore,  it  is  believed 
that  there  will  be  a requirement  for  deriving  a lexicon  of  standard  abbrevia- 
tions for  the  application  of  data  communication  in  satellite-supported  oceanic 
and  Continental  United  States  (CONUS)  ATC  systems. 

To  determine  an  answer  to  the  question  of  whether  there  was  a need  to  redesign 
the  fixed  format  used  for  data  communication  in  some  of  the  simulation  tests, 
the  event  logs  from  those  "choice"  tests  in  which  the  fixed  format  was  a test 
constraint  were  analyzed.  There  was  no  evidence  from  the  examination  of  these 
logs  that  the  controller  test  subjects  were  dissatisfied  with  the  use  of  the 
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fixed  foraat  data  message  and  therefore  resorted  to  using  voice  communication. 
Actually,  the  event  logs  show  that  59  percent  of  the  communication  transactions 
were  accomplished  through  data  messages,  while  the  remaining  41  percent  were 
accomplished  by  voice. 

To  determine  whether  the  short  text  message  (16  characters)  selected  for  the 
simulation  tests  was  sufficient  In  length  for  utilization  In  oceanic  ATC  communi- 
cations, It  was  postulated  that  If  there  was  a significant  difference  In  the 
amount  of  data  messages  for  tests  with  the  short-text  constraint  versus  those 
for  the  fixed  format  constraint,  this  might  Indicate  the  need  for  a longer 
short  text  message  length.  Analysis  of  the  event  logs  of  tests  for  both  test 
constraints  did  not  confirm  this  premise,  since  the  data  Indicated  that  there 
was  only  a small  difference  In  message  count,  5 percent  more,  for  tests  with 
the  short-text  constraint.  Some  explanation  for  this  can  be  drawn  from  the 
test  observer's  log  of  comments.  In  which  he  noted  that  most  controller  test 
subjects  were  able  to  cope  with  limited  character  messages  by  judicious  use  of 
abbreviations.  Conversely,  a close  examination  of  messages  sent  In  response  to 
pilots'  requests  for  changes  In  their  flight  plan  Indicated  that  In  many  Instances 
the  short  text  message  could  not  accommodate  all  of  the  Information  that  could 
have  been  sent  to  the  pilot  to  ensure  full  Information  clarification.  Naturally, 
for  those  situations  where  the  pilot  will  need  further  clarification  of  a 
message,  he  will  Initiate  another  communication  transaction;  however,  this 
action  will  Impact  on  channel  availability.  From  the  results  and  experience  of 
the  simulation  tests.  It  Is  recognized  that  certain  data  communication  trans- 
actions could  not  be  handled  expeditiously  If  limited  to  short  text  message  of 
16  character  length.  For  these  situations  under  this  limitation  either  long 
text  data  messages  or  voice  co^unlcation  would  be  required.  An  alternative 
to  the  utilization  of  cockpit  display  unit  designs  that  feature  limited  display 
capability  (most  designs  considered  to  date  have  only  2 rows  of  8 windows,  a 
total  capability  for  displaying  16  characters)  would  be  the  use  of  a small  CRT 
display  with  capability  for  the  display  of  3 lines  of  16  characters  each  or  a 
total  of  48  characters.  The  latter  concept  has  been  Investigated,  and  mockups 
have  been  constructed  and  checked  out  for  potential  future  application  in  the 
National  Aviation  Facilities  Experimental  Center  (NAFEC)  proposed  ATC  Automated 
Oceanic  Control  Center  (AOCC)  Satellite  Communications  Simulation  Testbed. 


CCmCLUSIONS 


Based  on  an  evaluation  of  subjective  Information  and  test  data.  It  Is  concluded 
that: 

1.  In  an  oceanic  ATC  communications  system  supported  by  satellites, 

75  percent  of  the  controller-to-pllot  communications  transactions  will  be 
accomplished  through  data  messages.  Voice  communication  will  be  used  by 
controllers  primarily  to  resolve  difficult  traffic  control  situations  or  in 
response  to  an  air-to-ground  voice  transaction  Initiated  by  the  aircraft  pilot. 

2.  Controllers,  once  exposed  to  a data  communication  system  for  use  In  oceanic 
ATC,  will  recognize  Its  efficiency  and  advantage,  especially  as  a positive  means 
for  transfer  of  control  Instructions  to  pilots,  and  especially  those  whose 
national  language  Is  not  English. 

3.  Standardization  of  abbreviations  and  control  symbols  Is  considered  an 
essential  system  design  goal  for  the  data  communication  operations  mode. 

4.  Controller  test  subjects  exposed  to  the  SSC/CAC  simulation  tests  tended  to 
adapt  their  communication  procedure  options  to  be  compatible  with  the  communi- 
cation system  discipline.  This  behavioral  pattern  should  be  anticipated 

for  whatever  satellite  oceanic  communications/surveillance  system  design  Is 
Implemented  for  AEROSAT. 

5.  The  experience  gained  from  design  of  the  SSC/CAC  simulation  testbed  and 
tests,  and  the  results  from  these  tests,  has  provided  valuable  expertise. 
Information,  and  data  for  application  in  future  simulation  efforts  relevant  to 
satellite  communications  systems  and  oceanic  ATC  automation. 


RECOMMENDATIONS 


To  assure  continuing  effort  in  the  acquisition  of  supportive  system  design  data 
and  operational  concepts/procedures  for  the  development  of  an  oceanic  ATC 
satellite  communications  system.  It  Is  recommended  that: 

1.  The  proposed  NAFEC  ATC  AOCC  Satellite  Communications  Simulation  Testbed  be 
utilized  for  further  and  more  comprehensive  tests  of  air  traffic  controllers' 
reactions  to  the  disciplines  of  the  satellite  mode  of  communications  and  their 
Interaction  with  related  Input /output  Interfaces. 

2.  These  tests  Incorporate  communication  delays  based  on  projected  user  popu- 
lations to  ensure  realism. 

3.  These  tests  feature  candidate  avlo.ilcs  Input/output  devices  In  at  least  one 
of  the  simulated  pilot's  positions. 

4.  The  experience.  Information,  and  test  results  obtained  from  the  SSC/CAC 
simulation  tests  delineated  In  this  report  be  utilized  In  the  proposed  NAFEC 
ATC  AOCC  Satellite  Communications  Simulation  Testbed. 
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Figure  Page 

A-1  Simulation  Testbed,  Data  Communication  Keyboard  Layout  A-7 

A-2  Simulation  Testbed,  Data  Communication  Long  Text  A-8 

Message  Printer 

A-3  Simulation  Testbed,  Simulated  Pilot's  Position  A-12 

Data  Communication  Display/Keyboard  Showing  a 
Typical  Presentation 


SITUATION  AND  TABULAR  DISPLAYS  FUNCTION  KEYBOARD  CONTROLS. 


The  situation  and  tabular  display  control  provisions  activated  by  means  of  the 
special  keyboard  were  as  follows: 

1.  Freeze/Resume  - Stopped  and  started  action  on  the  display. 

2.  Area  Keys  (1,  2,  3,  X)  - Allowed  the  controller  to  select  geographi- 
cal area  appropriate  to  the  sector  of  his  responsibility.  The  numbered  areas 


displayed  oceanic  coverage  as 

follows : 

Area 

1 

Lat  18“N  to 

45“N 

(27“) 

Lon  55 “W  to 

82  “W 

(27“) 

Area 

2 

Lat  13 “N  to 

74  “N 

(61“) 

Lon  8“W  to 

70“W 

(62“) 

Area 

3 

Lat  19“N  to 

65  “N 

(36“) 

Lon  27  “W  to 

63  “W 

(36“) 

Area 

X 

No  function 

programmed 

The  latitude  and  longitude  grid  was  displayed  In  1°  Increments. 

3.  Zoom  Key  - Expanded  the  center  of  map  In  four  steps.  Each  activation 
of  the  key  produced  an  increased  expansion.  Each  expansion  reduced  the  area  of 
coverage  by  approximately  half;  e.g. , area  1 covers  27“  of  latitude  by  27“  of 
longitude.  Zoom  1 reduced  the  area  to  13“  of  latitude  by  13“  of  longitude, 
zoom  2 to  7“  of  latitude  by  7“  of  longitude,  zoom  3 to  3“  of  latitude  by  3“  of 
longitude,  and  zoom  4 to  1“  of  latitude  by  1“  of  longitude.  The  normal  area 
coverage  was  restored  by  activation  of  the  associated  area  key. 

4.  Area  Display  Key  - Called  up  a menu  which  permitted  map  refinement  by 
means  of  the  situation  display  light  pen.  The  menu  provided  a choice  of  three 
predetermined  areas  in  addition  to  a discrete  zoom  and  window  function.  The 
zoom  provision  functioned  as  described  above.  The  window  feature  caused  any 
point  on  the  display  to  be  shifted  to  any  other  point  on  the  display  without 
affecting  the  total  number  of  degrees  displayed.  The  menu  for  the  "Area 
Display  Key"  is  described  below: 

AREA/DISPLAY 

*ERASE 

*AREA  1 
*AREA  2 
*AREA  3 
*ZOOM 
*WINDOW 

Note:  The  asterisked  items  in  the  above  and  following  described  menus  are 
computer  command  words.  To  execute  the  computer  command  the  light  pen  was 
pointed  at  any  part  of  the  selected  command  word  and  the  switch  on  the  side  of 
the  light  pen  was  depressed. 
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5.  Plot  Point  Key  - No  function  programmed. 

6.  Revise  Map  Key  - Called  up  a menu  which  enabled  the  controller  to  add 
or  delete  mapped  fixes,  routes,  or  boundaries  by  the  light  pen.  The  menu  for 
this  provision  is  described  below: 

REVISE  MAP 
*ERASE 

*FIX  *ADD 

*RTE  *DEL 

*BDRT 


7.  End  Revise  Map  Key  - No  function  programmed. 

8.  Map  Filter  Key  - Called  up  a menu  which  allowed  the  controller  to 
delete  or  recall  and  dim  or  brighten  the  map  features.  The  menu  for  this 
provision  is  described  below: 


MAP  FILTER 

*ERASE 

*LAT/LONG 

*0N 

*SECT  BDRT 

*OFF 

*OCB  EXTN 

*BRT 

*FIXES 
*FIX  IDS 
*RTES 
*SEL  RTE 

*DIM 

9.  Route  Flight  Level  Filter  Key  - Called  up  a menu  which  enabled  the 
controller  to  select  targets  by  flight  level,  and  delete  traffic  which  was  not 
in  his  area  of  responsibility.  The  menu  for  this  provision  is  described  below: 

RTL/FL 

FILTER  *ERASE 

*ALL  FL 
*HIGH 
*LOW 
*SEL  FL 

12  3 
4 5 6 
7 8 9 
0 

*RESTORE  ALL 
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10.  Flight  Plan  Route  Display  Key  - Called  up  a menu  that  allowed  the 
controller  to  depict  by  vectors  the  point  at  which  an  alerted  conflict  would 
take  place.  If  more  than  one  conflict  situation  existed,  the  menu  allowed 
display  or  Inhibition  of  the  fllghtpaths  of  all  or  selected  flights  and  would 
display  the  estimated  time  that  the  fllghtpaths  would  cross  associated  with 
the  aircraft  Identification  (ACID)  of  the  aircraft  Involved.  The  menu  for  this 
provision,  with  sample  aircraft  conflicts  and  times  of  occurrence.  Is  described 
below: 

FP/RTE/ALERT 

*ERASE 

*DPLAY 

♦INHIBIT 

*SEL 

♦ALL 

♦INTERSECT 

AC966 

0139 

NAl 

0130 

11.  Window  Keys  (window,  N,  S,  E,  and  W)  - The  activation  of  any  of  these 
keys  moved  the  map  In  5®  Increments  In  the  direction  opposite  that  described 

on  the  window  key.  The  window  keys  had  no  limit  on  the  number  of  activations. 

12.  Full  Data  Block  Key  - Called  up  a menu  which  enabled  the  controller 
to  offset  data  blocks  to  eight  points  equally  spaced  around  the  target  symbol, 
made  the  data  blocks  larger  or  smaller,  and  turned  the  data  blocks  ON  or  OFF. 
These  functions  could  be  applied  to  selected  data  blocks  or  to  all  data  blocks 
shown  on  the  display.  The  menu  for  this  provision  Is  described  below: 

FULL  DATA  BLOCK 
♦ERASE 

♦ALL  ♦LGR 

♦SEL  ♦SMLR 

♦ON 
♦OFF 

13.  Position  Vector  Key  - Called  up  a menu  which  enabled  the  controller 
to  vary  the  vector  length  emanating  from  target  blocks  to  reflect  aircraft 
future  position.  Choices  available  were  (In  minutes):  0,  10,  20,  30,  and  40. 
The  menu  for  this  function  Is  described  below: 

POS  VECT 
♦ERASE 

♦0  ♦lO  ^20 
♦30  ♦AO 
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14.  Accept  Altitude/Flight  Plan  Key  - This  key  became  active  when  a probe 
had  been  entered  into  the  computer.  Depression  of  this  key  would  then  update 
the  computer  data  bank  and  change  the  aircraft  data  block  to  reflect  the  air- 
craft altitude,  speed,  or  route  at  the  probed  output  value. 

15.  Reject  Altitude/Flight  Plan  Key  - This  key  became  active  when  a probe 
had  been  entered  Into  the  computer.  If  the  probe  allowed  a conflict,  this  key 
was  depressed  by  the  controller  to  nullify  probe  action.  This  key  was  also 
utilized  If  the  probe  indicated  clear,  and  It  was  desired  to  update  the  computer 
by  means  of  a ground-to-air  data  communication  message.  The  last  action  of  the 
controller  as  a result  of  a probe  had  to  be  the  use  of  either  the  "accept"  or 
"reject"  flight  plan  key.  This  completed  the  probe  and  freed  the  computer  to 
make  it  available  for  the  next  function  or  controller  action. 

16.  Accept  Progress  Report  Key  - This  key  became  active  whenever  the 
Information  in  a manually  entered  aircraft  position  report  was  not  In  agreement 
with  the  computer  data.  Depressing  this  key  overrode  the  computer  disagreement 
and  repositioned  the  aircraft  track  symbol  to  the  position  indicated  by  the 
progress  report  entry.  A flashing  "V"  symbol  near  the  aircraft  symbol  indica- 
ted the  progress  report  did  not  agree  with  the  computer  data  and  requested  a 
verification  be  made. 

17.  Reject  Progress  Report  Key  - This  key  functioned  in  a manner  similar 
to  the  "Accept  Progress  Report  Key"  except  that  it  was  used  to  reject  the 
manually  entered  aircraft  progress  report  whenever  there  was  disagreement  with 
the  computer  data.  Upon  rejection  of  the  manually  entered  progress  report,  the 
controller  had  to  re-enter  the  message  correcting  the  information  that  was  in 
error. 

18.  Tab/Sltuatlon  Display  Key  - This  key  was  used  by  the  controller  when- 
ever he  desired  to  replace  the  situation  map  displayed  on  the  situation  display 
with  either  of  two  tabular  displays,  the  selected  flight  plan  data,  or  the 
enroute  flight  plan  data. 

i i 

19.  Selected  Flight  Plans  Key  - Called  up  a tabular  list  of  all  ACID's 
that  were  active  in  the  simulation.  By  use  of  the  light  pen,  the  complete 
filed  flight  plan  of  one  or  more  aircraft  selected  would  be  displayed  on  the 
tabular  display. 

20.  Enroute  Data  Key  - Called  up  the  tabular  display  showing  "last 
reported  fix  data."  This  included  the  ACID,  actual  time  of  arrival  (ATA)  over 
last  fix,  flight  level  (FL) , next  fix,  computer  estimated  time  of  arrival  (CETA) , 
pilot-estimated  time  of  arrival  (PETA) , speed,  and  position  coordinates. 

21.  When  the  computer  detected  that  a conflict  had  occurred,  the  word 
"conflict"  appeared  flashing  on  the  lower  left  side  of  the  situation  display, 
with  the  ACID  of  the  two  or  more  aircraft  in  conflict  appearing  to  the  right 
of  the  word  "conflict".  The  position  vectors  of  the  aircraft  involved  also 
flashed.  The  flashing  message:  "Turn  off  alert,"  appeared  on  the  lower  right 
side  of  the  display.  These  indications  continued  until  the  alert  was  resolved. 
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22.  When  an  aircraft  position  update  was  not  received  by  the  system  within 
10  minutes  of  passing  a reporting  point  or  reporting  time,  an  alert  would  flash 
on  the  situation  display  in  the  form  of  the  word  "late"  near  the  aircraft  track 
symbol  and  the  words  "turn  off  alert"  would  appear  at  the  bottom  right  of  the 
display.  The  alerts  could  be  extinguished  by  updating  the  computer  or  be  over- 
ridden by  means  of  the  light  pen. 

All  menu  lists  that  were  called  up  required  light  pen  action;  however,  only  two 
menus  could  be  displayed  at  any  one  time.  Menus  displayed  had  to  be  erased  by 
light  pen  action  prior  to  replacement  with  another  menu. 

The  tabular  menu  lists  described  above  were  normally  displayed  on  the  designated 
"tabular  display"  (figure  2).  In  addition  to  the  menu  lists,  flight  plans  of 
aircraft  in  conflict  were  displayed  on  the  tabular  display.  When  a progress 
report  entered  into  the  computer  did  not  agree  with  the  computer  data,  the 
progress  report  was  displayed  in  alphanumerlcs  with  the  headings  of  the  dis- 
puted elements  flashing.  Late  alerts  were  displayed  next  to  the  ACID  and 
flight  plan  on  the  tabular  list.  In  conjunction  with  these  alert  displays, 
the  phrase  "turn  off  alert"  appeared  flashing  on  the  tabular  display. 

DATA  COMMUNICATION  DISPLAY  CONTROLS  AND  FUNCTIONS. 

The  data  communication  computer  terminal  display/keyboard,  which  was  the 
controller's  principal  input/output  (I/O)  device  for  addressing  the  computers 
and  simulated  pilot  position,  was  configured  through  special  software  residing 
In  computer  "B"  to  provide  certain  features  available  in  the  NAS  "D"  position 
Computer  Readout  Device  (CRD) . The  display  presentation  was  sized  to  the  same 
dimensions  as  the  CRD  and  formatted  to  contain  a computer  area  of  20  lines  and 
a preview  area  of  3 lines,  with  each  line  providing  a maximum  of  25  characters. 
These  two  areas  of  the  presentation  were  separated  by  a dashed  line.  The 
computer  area  was  reserved  for  display  of  all  information  being  either  received 
or  sent  by  the  controller.  The  preview  area  was  reserved  for  composing  and 
editing  of  all  message  contents  by  the  controller  prior  to  entering  that  infor- 
mation into  the  computer  for  processing.  The  computer  software  was  designed  to 
recognize  format  and  ACID  errors  and  cause  appropriate  error  indicators  to  be 
displayed  in  the  preview  area  in  order  to  alert  the  controller  of  an  improper 
input.  The  software  also  provided  the  display  of  the  ACID  in  the  preview  area 
automatically  upon  receipt  of  a message  from  an  aircraft  if  that  area  were  blank 
at  the  time.  This  feature  was  incorporated  for  controller  convenience  so  that 
he  would  not  have  to  enter  the  ACID  when  he  composed  an  answer  to  the  message. 

Information  that  appeared  in  the  computer  area  was  grouped  according  to  the 
aircraft  associated  with  the  communications'  transaction,  with  the  ACID  appear- 
ing to  the  left  of  the  first  line  in  each  message  group.  The  last  line  in  each 
message  group  was  the  last  communication  to  or  from  the  particular  aircraft. 

When  a new  ACID  with  associated  message  appeared  in  the  computer  area,  it 
occupied  the  top  line  of  the  presentation  and  caused  all  other  lines  to  scroll 
downward  one  line.  In  order  to  prevent  the  computer  area  from  becoming  filled 
to  capacity,  the  controller  had  the  provision  for  selectively  deleting  any 
group  of  messages  associated  with  an  ACID  or  consecutive  bottom  lines  of  the 
existing  presentation.  Manipulation  of  the  presentation  in  the  computer  and 
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preview  areas  was  accomplished  through  the  alphanumeric  and  quick  action  keys 
of  the  communication  display  keyboard.  Figure  A-1  shows  the  layout  of  the 
controller  data  communication  keyboard,  while  the  discussion  that  follows 
below  provides  a summary  description  of  the  keyboard  functions. 

The  data  communication  keyboard,  as  shown  In  figure  A-1,  contained  a set  of 
alphanumeric  typing  keys  similar  to  a standard  typewriter  keyboard  with  three 
exceptions.  There  was  a key  for  the  numeral  "1",  a "clear  key"  located  to  the 
left  of  the  letter  "Q"  key,  and  to  the  left  of  the  normal  apostrophe  key  was  an 
"enter"  key.  Adjacent  to  the  alphanumeric  keys  was  a set  of  10  "quick  action" 
keys  laid  out  similar  to  a standard  telephone  pushbutton  matrix.  To  the  right 
of  the  "quick  action"  keys  were  the  cursor  controls  and  editing  keys,  and  along 
the  far  right  edge  of  the  keyboard  were  the  mode  control  buttons  and  Indicators. 
The  majority  of  the  controller's  Inputs  required  use  of  the  typing  keys  and 
"quick  action"  keys.  When  a message  had  been  composed  and  edited  In  the  pre- 
view area.  It  was  transferred  to  the  computer  for  processing  by  means  of  the 
"enter"  key.  If  the  message  text.  Including  9 characters  for  ACID  as  a header, 
was  25  characters  total  or  less.  It  would  appear  as  entered  In  the  computer 
area.  If  there  was  more  than  25  characters  In  the  message.  It  would  be  printed 
out  on  the  long  text  printer  (figure  A-2)  associated  with  the  data  communication 
control  position.  However,  the  ACID  and  the  letters  "LT"  were  displayed  In  the 
computer  area  to  alert  the  controller  to  the  nature  of  the  message  and  the 
related  readout  device. 

The  clear  key  was  used  to  remove  all  Information  from  the  preview  area.  The 
transfer  of  an  aircraft  or  a computer  update  message  would  also  clear  the 
preview  area. 

Incoming  messages  to  be  displayed  on  the  CRD  were  signaled  to  the  controller 
by  an  audlo/vlsual  aid  In  the  form  of  a message-waiting  light  Indicator/push- 
button mounted  above  the  data  communication  display.  Upon  arrival  of  a message, 
the  Indicator  portion  of  the  "message  waiting"  light  Illuminated,  and  an  audio 
tone  sounded.  The  waiting  message  was  not  displayed  until  the  controller 
activated  the  pushbutton.  If  the  message  was  an  Initial  message  from  an  air- 
craft, It  would  appear  at  the  top  of  the  computer  area;  If  It  was  a reply  to  a 
message  from  the  controller  It  would  appear  under  the  previous  entries  for  that 
particular  ACID.  Such  messages,  since  they  could  appear  In  the  midst  of  a 
number  of  message  groups,  were  Identified  by  three  asterisk  symbols  placed  to 
the  left  of  the  message.  These  symbols  remained  displayed  for  15  seconds  to 
alert  the  controller  to  the  most  recent  message. 

As  noted  above,  messages  exceeding  25  characters  In  length  were  routed  to  the 
long  text  (LT)  printer,  and  the  associated  ACID  with  the  letters  "LT"  was 
displayed  In  the  computer  area. 

Messages  Identified  to  the  computer  as  "AT  messages"  and  controlled  through  the 
"AT"  quick  action  key  could  be  sent  In  two  forms,  formatted  and  unformatted. 
Formatted  messages  updated  the  computer  and  were  displayed  at  the  simulated 
pilot's  position;  unformatted  messages  were  displayed  at  the  simulated  pilot's 
position  only.  Unformatted  "AT"  messages  were  limited  to  72  characters  In 
length.  Including  the  ACID  and  the  "AT"  symbol,  but  could  be  composed  In  plain 
language  and  In  any  form. 
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FIGURE  A-1.  SIMULATION  TESTBED,  DATA  COMMUNICATION  KEYBOARD  LAYOUT 


FIGURE  A- 2.  SIMULATION  TESTBED,  DATA  COMMUNICATION  LONG  TEXT  MESSAGE  PRINTER 
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"Probe,”  message  identifier  symbol  "AP,"  was  normally  addressed  to  the  computer 
prior  to  complying  with  a pilot  request  for  an  altitude  or  airspeed  change.  If 
^ the  requested  change  would  not  cause  a conflict,  the  word  "clear"  would  flash  on 

the  lower  right  portion  of  the  situation  display.  If  the  change  would  bring  the 
flight  into  any  conflict,  the  word  "conflict"  would  appear  on  the  lower  right 
portion  of  the  situation  display,  and  the  position  vectors  of  the  aircraft 
Involved  would  flash.  When  the  probe  of  an  altitude  was  made,  the  associated 
data  block  would  show  the  aircraft  at  the  probed  altitude.  In  the  case  of  a 
probe  showing  "clear,"  the  "accept  altltude/FP"  key  on  the  situation  display 
function  key  panel  could  be  depressed,  and  the  probed  altitude  or  airspeed  would 
be  Incorporated  Into  the  computer  data.  This  action  would  normally  be  done  if 
the  change  request  was  made  through  a voice  channel  transaction.  The  controller 
could  clear  the  flight  for  the  change  by  voice  and  update  the  computer  by 
accepting  the  probe  on  the  function  key  panel.  If  the  requested  change  was  made 
through  data  communication,  then  the  "reject  altitude/FP"  key  on  the  function 
key  panel  could  be  utilized  to  reject  the  probe,  since  the  requested  altitude/ 
airspeed  clearance  would  be  sent  to  the  pilot  via  data  communication,  updating 
the  computer  and  data  block  at  the  same  time.  In  the  case  where  the  probe  showed 
a conflict,  then  the  probed  altitude/airspeed  would  be  rejected,  and  an  alternate 
altitude/airspeed  probed. 

"Request  voice,"  message  identifier  symbol  "RV,"  was  the  provision  used  by 
the  controller  to  request  the  computer  to  assign  a voice  channel  to  any  indivi- 
dual aircraft  identified.  As  indicated  previously  in  the  report,  voice  commun- 
ication provisions  in  the  simulation  tests  were  under  computer  control  just  as 
they  would  be  in  an  actual  ATC  satellite  communications  system.  If  the  control- 
ler or  pilot  needed  to  communicate  by  voice,  they  had  to  request  a voice  channel. 
Once  a voice  channel  was  requested,  the  computer  would  delay  activation  of  the 
channel  for  the  period  of  channel  access  time  delay  designed  into  the  test. 
Activation  of  a voice  channel  by  the  computer  caused  a "voice  channel  active" 
indicator  light  at  the  controller's  position  to  be  illuminated  and  an  identify- 
ing symbol  "-V-"  was  displayed  under  the  ACID  in  the  computer  area  of  the  CRD. 

"End  voice,"  message  identifier  symbol  "EV,"  was  the  provision  used  by  the 
controller  to  request  the  computer  to  deactivate  the  voice  channel  between  him- 
self and  the  simulated  pilot.  The  voice  channel  request  provisions  in  the  sim- 
ulation testbed  were  designed  so  that  either  the  controller  or  pilot  could 
request  a voice  channel,  but  only  the  controller's  position  could  request  termi- 
nation of  the  voice  channel.  When  the  "EV"  message  was  entered  unto  the  compu- 
ter by  the  controller,  the  "voice  channel  active"  indicator  was  extinguished, 
and  the  letter  "-V-"  was  removed  from  the  CRD. 

"Delete  data,"  message  identifier  symbol  "DD,"  enabled  the  controller  to 
delete  information  in  the  computer  area  of  the  CRD.  It  was  the  only  "quick 
action  key"  function  that  could  be  activated  before  the  ACID  was  entered.  The 
"DD"  key  could  be  used  in  two  ways.  First,  the  key  could  be  depressed  as  many 
times  as  there  were  lines  of  data  displayed,  and  upon  activation  of  the  "enter" 
key,  one  line  of  data  would  be  deleted  for  each  time  the  "DD"  key  was  depressed. 
Deletion  of  the  data  was  accomplished  from  the  bottom  to  the  top  of  the  CRD 
presentation.  If  the  "DD"  key  was  depressed  more  times  than  there  were  lines 
of  data  in  the  computer  area,  no  action  occurred  when  the  "enter"  key  was 
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activated.  The  second  use  of  the  "DD"  key  was  to  delete  all  information  on  any 
particular  aircraft  shown  In  the  computer  area.  This  was  accomplished  by 
depressing  the  "DD"  key,  typing  In  the  aircraft  ID,  and  activating  the  "enter" 
key.  All  Information  associated  with  that  ACID  was  deleted,  and  any  other  air- 
craft message  groups  displayed  below  the  deleted  Information  would  move  up  to 
fill  In  the  vacated  space. 

"Progress  report."  message  Identifier  symbol  "PR,"  enabled  the  controller  to 
manually  enter  aircraft  position  report  data  Into  the  computer.  Progress 
reports  which  were  not  received  automatically  by  the  computer  through  data 
communication,  such  as  those  received  by  the  controller  during  voice  channel 
simulation  tests,  were  manually  entered  Into  the  computer  data  bank  by  the 
controller.  If  the  position  data  did  not  agree  with  the  computer- Interpolated 
position  data,  a "verify  alert"  was  flashed  on  the  situation  display.  This 
alert  action  required  the  controller  to  either  accept  or  reject  the  computer- 
derived  position  report  data  through  an  Input  on  the  situation  display  func- 
tion keyboard. 

"Flight  plan,"  message  identifier  symbol  "FP,"  was  a provision  used  by  the 
controller  to  enter  a new  flight  plan  Into  the  computer  data  bank.  This  require- 
ment would  occur  whenever  an  aircraft  Initiated  an  "air  file"  flight  plan. 
Following  the  controllers'  entering  of  the  flight  plan  Information  and  an 
"activate  flight  plan"  message  to  the  computer,  the  target  symbol  and  related 
flight  Information  would  appear  on  the  situation  display,  and  the  flight  was 
listed  on  the  tabular  display. 

"Activate  flight  plan,"  message  Identifier  "AC,"  was  the  provision  used  by  the 
controller  to  activate  a flight  plan  after  It  was  manually  entered  Into  the 
computer.  No  flight  plan  Information  would  appear  on  the  situation  display 
until  the  flight  plan  was  activated;  however.  If  the  controller  had  a need  for 
its  display,  the  flight  plan  could  be  called  up  on  the  tabular  display  prior  to 
activation.  The  time  of  activation  entered  Into  the  computer  had  to  be  at  a 
future  time  of  the  problem  time. 

"Hold/delay,"  message  Identifier  "HD,"  enabled  the  controller  to  stop  the 
progress  of  a flight  in  response  to  a pilot  request  or  ATC  requirement.  The 
message  contained  the  ACID,  "HD"  Identifier,  and  a time.  The  time  entered  was 
the  "end  time"  at  which  the  aircraft  would  hold  Its  present  position.  The 
situation  display  presentation  would  show  a nonmoving  target  symbol.  The  air- 
craft target  would  remain  fixed  on  the  display  until  the  controller  caused  it 
to  resume  on  course  by  Initiating  an  "AT"  message.  When  the  "AT"  message  is 
used  to  clear  an  aircraft  on  course,  a "PR"  message  must  be  entered  Into  the 
computer  to  cause  It  to  resume  the  extrapolation  of  the  target  again. 

"Cancel."  message  Identifier  "CX,"  was  the  provision  used  by  the  controller  to 
delete  all  Information  on  file  In  the  computer  In  connection  with  the  aircraft 
Identified  and  to  cause  deletion  of  all  situation  and  tabular  display  informa- 
tion. 
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SIMULATED  PILOT'S  DISPLAY  CCWTROLS  AND  FUNCTIONS. 


The  display  used  for  the  simulated  pilot's  position  provided  the  capability  of 
12  lines  of  72  characters  each  for  display  of  data  communication  messages 
entered  and  received  by  the  simulated  pilot.  The  keyboard  was  employed  essen- 
tially as  a normal  computer  terminal  keyboard  with  the  following  exceptions: 
messages  entered  Into  the  computer  data  bank  were  activated  by  means  of  the 
"return"  key  and  a provision  was  made  for  a single  back-space  error  correction 
for  use  when  composing  messages.  The  latter  was  accomplished  by  depressing  the 
"control"  key  together  with  the  "H"  character  key.  Figure  A-3  shows  a view  of 
the  display  and  keyboard  with  typical  data  communication  messages  displayed. 

There  were  only  two  computer  message  Identification  symbols  available  to  the 
simulator  pilot;  "AT"  for  an  ATC  message  and  "RV"  for  requesting  a voice 
channel . When  the  simulated  pilot  requested  a voice  channel,  the  computer 
caused  an  alert  message  "VOICE  CHANNEL  READY****  GO  AHEAD"  to  appear  on  the 
display  upon  Its  activation  of  the  voice  channel.  If  the  simulated  pilot,  upon 
entering  a message  Into  the  computer,  used  an  Incorrect  format  or  ACID  not  In 
the  computer  data  bank,  the  computer  caused  an  error  alert  message  to  be 
displayed.  This  action  negated  the  entire  message  and  required  that  the  complete 
message  be  recomposed  and  re-entered  correctly. 


SHOWING  A TYPICAL  PRESENTATION 
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MATERIAL  ON  SSC/CAC  SIMULATION  TESTS 


SSC/CAC  SIMULATION  TEST  TRAFFIC  SAMPLES 


TRAFFIC  SAMPLE  NO.  1 

FLIGHT  PLANS 


ACID 

TYPE 

A/S 

DPT 

ALT 

ETD 

ROUTE  OF  FLIGHT 

VA  750 

DC8/A 

480 

SJU 

350 

POlOO 

S JU , RFT , END , TUNA , JFK 

AA677 

H747/A 

485 

BOS 

410 

POlOO 

BOS, 3400/07040, CLA, END, RFT, SJU 

EA  444 

B727/A 

435 

ZQA 

310 

POlOl 

ZQA, 2900/07 600 , LAM, TUNA, JFK 

PA  262 

B727/A 

430 

SJU 

350 

P0102 

S JU , GAN , GNY , GLD , JFK 

VVWX60 

P3/A 

320 

BDA 

250 

P0102 

BDA, 3200/06700, GTN, CLA, 3045/ 
07445, JAX 

AA  215 

H707/A 

480 

CHS 

330 

P0105 

CHS ,3420/07340, 2700/07010, SJU 

PA  292 

H747/A 

485 

SJU 

390 

P0112 

SJU, 2600/06630, GNY, GTN, GLD, BOS 

NA  1 

H747/A 

485 

PBI 

370 

P0125 

PBI,DAR,CSH,CER,BDA,SNN 

AC  966 

DC8/A 

480 

YYR 

370 

P0117 

YYR, 3500/06620, BDA, 2950/06500, 
2700/06525, SJU 

EA  963 

LlOl/A 

485 

BOS 

290 

P0122 

BOS , 34 00/07 040 , CLA , END , RFT , SJU 

W53615 

P3/A 

325 

GTN 

240 

POlOO 

GTN. CLA. 3045/07445, JAX  (AIRFILE) 

N 42 

B707/A 

480 

ACY 

290 

00100 

ACY,  TUNA,  BMN,  CLE,  END,  SJU 

TW  101 

B707/A 

480 

BOS 

330 

POlOO 

BOS,  PKE,  TNG,  DAR,  JAX 

AC  967 

DC8/A 

480 

SJU 

310 

POlOO 

SJU,  GUA,  GAN,  GNY,  LAM,  CLA,  BDA 

DL  202 

B727/A 

480 

PBI 

270 

POlOO 

PBI,  JAX,  CHS,  LAM,  CLA,  BDA 
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TRAFFIC  SAMPLE  NO.  2 


FLIGHT  PLANS 


ACID 

TYPE 

A/S 

DPT 

ALT 

ETD 

ROUTE  OF  FLIGHT 

DO  920 

DC8/A 

480 

SJU 

350 

PIOOO 

SJU , RFT , END , TUNA, JFK 

DL  555 

H747/A 

485 

BOS 

330 

POlOO 

BOS , 3 4 00/ 07 04 0 , CLA , END , RFT , S JU 

AA  224 

B727/A 

435 

ZQA 

310 

POlOl 

ZQA, 2900/07 600, WIL, LAM, TUNA, JFK 

PA  112 

B727/A 

430 

SJU 

350 

P0102 

S JU , GAN , GNY , GLD , JFK 

M16262 

C131/A 

320 

BDA 

250 

P0102 

BDA,3200/06700, GTN, CLA, 3045/ 
07445, JAX 

SO  117 

B727/A 

480 

CHS 

330 

P0105 

CHS ,3420/07340, 2700/07010, SJU 

TW  666 

H747/A 

485 

SJU 

390 

P0112 

SJU, 2600/06630, GNY, GTN, GLD, BOS 

TW  11 

H747/A 

485 

PBI 

370 

P0125 

PBI,DAR,CSH,CER,BDA,SNN 

AC  818 

DC8/A 

480 

YYR 

370 

P0117 

YYR, 3500/06620, BDA, 2950/06500, 
2700/06525, SJU 

AA  633 

LlOl/A 

485 

BOS 

290 

P0122 

BOS , 3400/ 07 04 0, CLA , END , RFT , SJU 

N lAP 

B707/A 

480 

ACY 

370 

POlOO 

ACY , TUNA , BMN , CLA , END , SJU 

UA  35 

B707/A 

480 

BOS 

330 

POlOO 

BOS , PKE , TNG , DAR, JAX 

MPDXC 

DC3/A 

480 

SJU 

310 

POlOO 

SJU , GUA , GAN , GNY , GTN , ROY , YYR 

N 600F 

B727/A 

480 

PBI 

270 

POlOO 

PBI , JAX , CHS , LAM , CLA , BBDA 

TROL  22 

Pj/A 

325 

GTN 

240 

POlOO 

GTN. CLA. 3045/07445, JAX  (AIRFILE) 
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f ' FLIGHT  PLANS 


ACID 

TYPE 

A/S 

DPT 

ALT 

ETD 

ROUTE  OF  FLIGHT 

AF  110 

DC8/A 

480 

SJU 

350 

POlOO 

S JU , RFT , END , TUNA , JFK 

EA  997 

LlOl/A 

185 

BOS 

330 

POlOO 

BOS , 3400/07040 , CLA , END , RFT , SJU 

EA  626 

B727/A 

435 

ZQA 

310 

POlOl 

ZQA , 2900/07600 , WIL , LAM , TUNA , JFK 

AA  600 

B727/A 

430 

SJD 

350 

P0102 

S JU , GAN , GNY , GLD , JFK 

DORKIO 

P3/A 

250 

BDA 

250 

P0102 

BDA , 3200/06 700 , GTN , CLA , 3045 / 
07445, JAX 

DL  377 

B727/A 

480 

CHS 

330 

P0105 

CHS, 3420/07340, 2700/07010, SJU 

PA  866 

H747/A 

485 

SJU 

390 

P0112 

SJU , 2600/06630 , GNY , GLD , BOS 

BA  100 

H747/A 

485 

PBI 

370 

P0125 

PBI ,DAR,CHS ,CER, BDA, SNN 

AF  260 

DC8/A 

480 

YYR 

370 

P0117 

YYR, 3500/06620, BDA, 2950/06500, 

2 700/06525, SJU 

TW  431 

LlOl/A 

485 

BOS 

290 

P0122 

BOS,  3400/07040, CLA,END, RFT, SJU 

N500MA 

FFJ/A 

480 

ACY 

370 

POlOO 

AC Y , TUNA , BMN , CLA , END , S JU 

EA  265 

B707/A 

480 

BOS 

330 

POlOO 

BOS , PKE , TNG , DAR , JAX 

A2 

B707/A 

480 

SJU 

310 

POlOO 

S JU , GUA , GAN , GNY , GTN , ROY , YYR 

BN  102 

B727/A 

480 

PBI 

270 

POlOO 

PBI , JAX , CHS , LAM , C LA , BDA 

STU069 

P3/A 

325 

GTN 

240 

POlOO 

0/GTN, CLA, 3045/07445 , JAX 

SCRIPT  NO.  1 


ITEM  NO. 

INIT 

ACID 

ACTION 

1 

(P) 

NA  1 

RFL  410 

2 

(P) 

EA  444 

REQ  SPEED  425  KTS,  TURBULENCE 

3 

(C) 

EA  963 

SAY  YOUR  FLIGHT  CONDITIONS 

4 

(P) 

VVWX60 

REQ  RETURN  TO  BDA,  NO.  1 ENGINE  OUT 

5 

(P) 

AA  215 

RFL  290,  CAT 

6 

(C) 

AA  677 

SAY  YOUR  AIRSPEED 

7 

(P) 

W53615 

AIRFILE:  0/BDA  GTN  CLA  MIK  JAX.  RFL  240, 

P3/A,  325  KTS 

8 

(C) 

AC  966 

ATC  REROUTE;  TO  SJU  VIA  3000/06400  2700/06300 

SJU  370 

9 

(P) 

TW.lOl 

REQ  HOLD  PRES.  POS.  10  MINUTES 

10 

(C) 

AC  966 

DESCEND  TO  FL  200 

11 

(P) 

N42 

REQ  SATELLITE  DERIVED  POSITION 

12 

(P) 

AC  967 

RFL  350 

13 

(P) 

DL  202 

RFL  370 

14 

(P) 

NA  1 

REQ  COMPUTER  ETA  FOR  NEXT  FIX 

USE  TRAFFIC 

SAMPLE 

NO.  1 

CANCEL  W53615  PRIOR  TO  NEXT  RUN 


! 
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SCRIPT  NO.  2 


ITEM  NO. 

INIT 

ACID 

1 

(P) 

AA  677 

2 

(P) 

PA  262 

3 

(C) 

TW  101 

4 

(P) 

VVWX60 

5 

(P) 

EA  963 

6 

(C) 

AC  967 

7 

(P) 

W53615 

8 

(P) 

TW  101 

9 

(P) 

NA  1 

10 

(C) 

AC  967 

11 

(P) 

TW  101 

12 

(P) 

VVWX60 

13 

(P) 

PA  262 

14 

(P) 

N 42 

USE  TRAFFIC 

SAMPLE  NO 

. 1 

CANCEL  W53615  PRIOR 

TO  RUN 

ACTION 

RFL  430 

REQ  SPD  400  KTS 

SAY  AIRSPEED 

REQ  REROUTE  TO  JAX 

RFL  200 

SAY  AIRSPEED 

AIRFILE;  0/BDA  GTN  CLA  MIK  JAX,  RFL  240, 
P3/A,  325  KTS 

REQ  REROUTE  TO  JFK 

REQ  HOLD  FOR  10  MINUTES  PRES.  POS. 

CLIMB  TO  FL  330 

REQ  SATELLITE  DERIVED  POSITION 
RFL  200 
RFL  370 

REQ  COMPUTER  ETA  FOR  NEXT  FIX 


B-5 

„ J 


SCRIPT  NO.  3 


ITEM  NO. 

INIT 

ACID 

ACTION 

1 

(P) 

AA  224 

RFL  280 

2 

(P) 

TW  11 

REQ  SPEED  425  KTS,  TURBULENCE 

3 

(C) 

PA  112 

ATC  REQ;  VERIFY  AT  FL  350 

4 

(P) 

M16262 

REQ  REROUTE  TO  CHS  VIA  PRES  POS  CLA  LAM  CHS 

5 

(P) 

SO  117 

RFL  370 

6 

(C) 

AA  633 

ATC  ADVISORY:  SATELLITE  SHOWS  YOU  20  NM  WEST 
OF  CRS 

7 

(P) 

TROL22 

AIRFILE:  0/BDA  CLA  MIK  JAX.RFL  240,  P3/A, 

325  KTS 

8 

(P) 

UA  35 

REQ  REROUTE  TO  BDA 

9 

(P) 

UA  35 

REQ  LOWER  ALTITUDE 

10 

(C) 

AC  818 

DESCEND  TO  FL  200 

11 

(C) 

N lAP 

ATC  REQ:  MAKE  MANUAL  POSITION  REPORT 

12 

(P) 

MPDXC 

RFL  350 

13 

(P) 

N 600F 

RFL  370 

14 

(P) 

TW  666 

REQ  SATELLITE  DERIVED  POSITION 

USE  TRAFFIC  SAMPLE  NO.  2 
CANCEL  TROL22  PRIOR  TO  NEXT  RUN 


SCRIPT  NO.  4 


ITEM  NO. 

INIT 

ACID 

1 

(P) 

AA  224 

2 

(P) 

TW  11 

3 

(C) 

PA  112 

4 

(P) 

M16262 

5 

(P) 

SO  117 

6 

(C) 

AA  633 

7 

(P) 

TROL  22 

8 

(P) 

UA  35 

9 

(P) 

UA  35 

10 

(C) 

TW  666 

11 

(C) 

N lAP 

12 

(P) 

MPDXC 

13 

(P) 

TW  666 

14 

(P) 

AC  818 

USE  TRAFFIC 

SAMPLE  NO 

1.  2 

CANCEL  TROL 

22  PRIOR 

TO  RUN 

ACTION 

RFL  310 

REQ  SPEED  480  KTS 

ATC  REQ;  VERIFY  AT  FL  350 

REQ  REROUTE  TO  SJU  VIA  PRES  POS  CLA  END  SJU 

RFL  330 

ATC  ADVISORY!  SATELLITE  SHOWS  YOU  20  NM  WEST 
OF  CRS 

AIRFILE;  0/BDA  CLA  MIK  JAX,  RFL  240,P3/A, 

325  KTS 

REQ  REROUTE  TO  SJU 
REQ  HIGHER  ALTITUDE 
DESCEND  TO  FL  200 

ATC  REQ;  MAKE  MANUAL  POSITION  REPORT 
RFL  270 

REQ  SATELLITE  DERIVED  POSITION 
REQ  COMPUTER  ETA  NEXT  FIX 


i| 
■ i 


I 
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SCRIPT  NO.  5 


ITEM  NO. 

INIT 

ACID 

ACTION 

1 

(P) 

BA  100 

RFL  410 

2 

(P) 

EA  626 

REQ  SPEED  415  KTS 

3 

(C) 

DORKIO 

REQ  REROUTE  TO  SJU 

4 

(P) 

DL  377 

RFL  190 

5 

(C) 

EA  997 

ATC  ADVISORY:  SATELLITE  SHOWS  YOU  20  NM 
EAST  OF  CRS 

6 

(P) 

STUD69 

AIRFILE:  0/BDA  GTN  CLA  3045/07445  JAX. 
P3/A,  RFL  240  325  KTS 

7 

(C) 

AF  260 

ATC  REROUTE:  TO  SJU  VIA  PRES.  POS.  GNY  ( 
SJU 

8 

(P) 

EA  265 

REQ  HOLD,  PRES  POS,  5 MINUTES 

9 

(C) 

AF  260 

DESCEND  TO  FL  230 

10 

(P) 

EA  265 

REQ  REROUTE  TO  BOS 

11 

(C) 

N500MA 

ATC  REQ:  MAKE  MANUAL  POSITION  REPORT 

12 

(P) 

A2 

RFL  350 

13 

(P) 

BN  102 

RFL  370 

14 

(P) 

FA  866 

REQ  SATELLITE  DERIVED  POSITION 

USE  TRAFFIC  SAMPLE  NO.  3 
CANCEL  STUD69  PRIOR  TO  NEXT  RUN 
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SCRIPT  NO.  6 


ITEM  NO. 

INIT 

ACID 

ACTION 

1 

(P) 

BA  100 

RFL  370 

2 

(P) 

EA  626 

REQ  SPEED  480  KTS 

3 

(C) 

EA  997 

ATC  ADVISORY;  SATELLITE  SHOWS  YOU  20  NM 

EAST  OF  CRS 

4 

(P) 

DORKIO 

REQ  REROUTE  TO  JAX 

5 

(P) 

DL  377 

RFL  330 

6 

(C) 

EA  997 

ATC  ADVISORY:  SATELLITE  SHOWS  YOU  BACK  ON 
COURSE 

7 

(P) 

STUD69 

AIRFILE:  0/BDA  GTN  CLA  3045/07445  JAX, 

P3/A,  RFL  240,  325  KTS 

8 

(C) 

AF  260 

ATC  REROUTE;  TO  BDA  VIA  PP  2700/06300  3000/ 
06400  BDA 

9 

(P) 

EA  265 

REQ  HOLD  PRES  POS  FOR  10  MINUTES 

10 

(C) 

AF  260 

DESCEND  TO  FL  210 

11 

(P) 

EA  265 

REQ  REROUTE  TO  JAX 

12 

(C) 

N500MA 

ATC  REQ;  MAKE  MANUAL  POSITION  REPORTS 

13 

(P) 

A2 

RFL  310 

14 

(P) 

PA  866 

REQ  SATELLITE  DERIVED  POSITION 

USE  TRAFFIC 

SAMPLE 

NO.  3 

CANCEL  STUD69  PRIOR  TO  RUN 


SSC/CAC  SIHULATION  TEST  GENERAL  QUESTIONNAIRE 


Question: 

1.  Waiting  times  on  the  voice  channel  were:  (V/C) 

a.  Acceptable 

b.  Unacceptable 

2.  Circle  the  channel  you  found  best  in  this  test.  (C) 

a.  Voice 

b.  Data 

Why: 

3.  The  channel  provided  In  this  test  was  better  for  (C) 

resolving  difficult  control  situations. 

a.  Data 

b.  Voice 

4.  1 estimate  that  a controller  will  use  the  voice  channel  (End) 
approximately : 

a.  25  percent  or  less 

b.  50  percent 

c.  75  percent 

d.  90  percent  or  more  of  the  time 

5.  I found  the  message  types  that  could  be  sent  on  the  data  (D/C) 
channel  which  was  provided  In  this  test: 

a.  Sufficient 

b.  Insufficient 

Explain : 

6.  Did  you  use  the  voice  more  than  you  wanted  to  when  restric-  (C) 
tlons  were  placed  on  the  length  of  a data  message? 

a.  Yes 

b.  No 

Explain: 

7.  The  pre-defined  message  types  were:  (C/D) 

a.  Acceptable 

b.  Unacceptable 


SSC/CAC  SOWLATION  TEST  GENERAL  QUESTIONNAIRE  (CCWT'D) 

8.  The  following  describes  my  feeling  about  data  link  (more  than 
one  answer  is  acceptable): 

a.  I would  rather  use  it  than  the  satellite  voice  channel 

b.  It  has  limited  use 

c.  It  can  supplement  the  voice  channel 

Explain : 

9.  List  the  message  types  that  lend  themselves  readily  to  the  use 
data  link. 

10.  List  your  key  features  of  satellite  system  for  oceanic  air 
control. 


Legend:  V/C  - Voice  Only  and  Choice  Voice  or  Data  Tests 
C - Choice  Voice  or  Data  Tests 
D/C  - Data  Only  and  Choice  Voice  or  Data  Tests 
End  - To  be  answered  after  completion  of  all  ten  test  runs. 


(D/C) 

(D/C) 

(End) 
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SSC/CAC  SIHULATKW  TEST  DATA  COMMUNICATION  READOUT  DEVICE  QUESTIONNAIRE 


1.  The  Information  displayed  on  the  CRD  was: 

a.  Acceptable 

b.  Unacceptable 

2.  The  size  of  the  preview  area  was: 

a.  Good 

b.  Bad 

Explain: 

3.  The  size  of  the  computer  area  was: 

a.  Good 

b.  Bad 

Explain: 

4.  The  automatic  ACID  feature  In  the  preview  area  was: 

a.  Helpful  and  easy  to  use 

b.  Confusing  and  difficult  to  use 

5.  Methods  of  deleting  Information  were: 

a.  Satisfactory  j 

b.  Unsatisfactory  | 

6.  The  overall  use  of  the  CRD  for  air-to-ground  communication  was:  | 

a.  Acceptable 

b.  Unacceptable 

7.  The  Quick  Action  Keys  provided  were: 

a.  Too  many 

b.  Not  enough 

c.  About  right 

8.  List  any  Improvements  you  would  like  to  see  implemented. 
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SSC/CAC  ABBREVIATIONS  FOR  COMPOSING  DATA  COHMUNICATION  MESSAGES 

PP  - PRESENT  POSITION 
HD  - HOLD 

PR  - PROGRESS  REPORT 
CRS  - COURSE 

RFL  - REQUEST  FLIGHT  LEVEL 

RSP  - REQUEST  SPEED 

RRR  - REQUEST  REROUTING 

RR  - REROUTE 

RDV  - REQUEST  DEVIATION 

UN  - UNABLE 

TURB  - TURBULENCE 

WILCO  - WILL  COMPLY 


B-13 


